rnoland: vehemens: ok, I think that your patch should work....
rnoland: I think the DRM_DEBUG("page entry %d: 0x%016llx\n", i, page_base); was correct as an ll.
rnoland: what was the behavior you saw?
vehemens: compiler warning
rnoland: on amd64?
rnoland: hrm... it is correct on i386
vehemens: shouldn't hurt to leave it for now. or ifdef it for the linux folks.
rnoland: vehemens: try this
rnoland: DRM_DEBUG("page entry %d: 0x%016llx\n", i,
rnoland: (unsigned long long)page_base);
rnoland: airlied: does the above work for you?
vehemens: no warning here. need to find my c99 spec.
rnoland: u64 == long on amd64 and long long on i386
rnoland: so i think we avoid warnings in all cases by casting it....
rnoland: i'm not sure if a long long on amd64 is 64 or 128 bits, but....
rnoland: either way, we will output 16 hex digits...
vehemens: from printk-formats.txt: u64 SHOULD be printed with %llu/%llx, (unsigned long long):, printk("%llu", (unsigned long long)u64_var);
rnoland: dunno, but if i change it to a long, i get a warning and build dies...
rnoland: and you have the opposite case...
rnoland: if airlied will ack that it works for him, i'll push all of this....
chithead: actually for c99, u64 should use the PRIu64 modifier
rnoland: well, i don't care what it is, as long as it works on i386/amd64....
chithead: unsigned long is printed wth %lu, unsigned long long with %llu but neither is guaranteed to be exactly 64 bits (long long is required to be at least 64 bits though)
vehemens: my above note is in the linux kernel documentation. the freebsd amd64 doc matches for this case.
vehemens: besides, when has anyone compiled a kernel with no warnings :)
chithead: maybe this is for compatibility to non-c99 compilers then
rnoland: vehemens: the drm build is -Werror
rnoland: #define PRIu64 "lu" /* uint64_t */
rnoland: #define PRIu64 "llu" /* uint64_t */
vehemens: so if def it for freebsd amd64
rnoland: thats just ugly.
vehemens: the drm code isnt' that pretty. so who would notice :)
rnoland: we *are* trying to improve things...
vehemens: so what's the solution, no r6xx-r7x drm for freebsd because of a warning? :)
rnoland: what i have works correctly and doesn't warn...
rnoland: if someone has a more correct solution, i'm all ears?
vehemens: if the solution is the one you gave me to try, then it should be fine as it matches the linux kernel docs
rnoland: which, the cast to (unsigned long long)
rnoland: that works on i386 and amd64
rnoland: yeah, that is the best solution I have at the moment...
rnoland: there should be some way to use PRIx64, but I don't know how....
vehemens: need sleep. good luck with the patch.
rnoland: aight, night.
rnoland: chithead: do you guys have a define for PRIx64 via inttypes.h?
rnoland: chithead: could you try this?
rnoland: DRM_DEBUG("page entry %d: 0x%016" PRIx64 "\n",
rnoland: i, page_base);
rnoland: ugh, ok... need airlied.
airlied: rnoland: unsigned long long is fine
rnoland: airlied: i have it working with PRIx64 for me now
rnoland: if you guys can make the work right, it does seem more correct...
airlied: I don't think we have PRIx64 in the kernel
rnoland: airlied: DRM_DEBUG("page entry %d: 0x%016" PRIx64 "\n", i, page_base);i
rnoland: i had to add an include of
airlied: actually I lie we do have one but its defined in one C file.
airlied: so unlikely to be used
airlied: (unsigned long long) should be portable with %llx
rnoland: yeah, it works for me....
davem1: u64 is always long long these days, so no need for tom-foolery like PRIx64
airlied: davem1: we have uint64_ts in some places, which I persume as different just for lols.
rnoland: well, for us... on i386 long is u32
rnoland: and on amd64 long is u64
davem1: long is always %lx
davem1: u64 is always %llx
rnoland: well, u64 isn't an llx on amd64
rnoland: it is just lx
davem1: goes to check the code
airlied: davem1: FreeBSD :)
airlied: when he saays us
davem1: oh, all bets off if you're on Mars
davem1: sorry about that
rnoland: so casting it, should make everything happy....
davem1: that's what we used to do in Linux before we pulled out heads out of our asses
moeSizlak: ok the newest f10 kernel with nomodeset actually seems to let me run compiz stably.
moeSizlak: when will the mainline kernel catch up w/ the f10 kernel as far as patches that allowed this to happen
EruditeHermit: hey all how goes
MrCooper: mo3sizlak: sooner if you help identify the fixes
MostAwesomeDude: airlied: FYI, my RV410 also doesn't like that new kernel.
MostAwesomeDude: Plymouth doesn't matter, RHGB doesn't matter. When I start X, it hangs hard.
Kano: hi agd5f
Kano: agd5f: when will be 6.12 out?
Kano: or 6.11.99
airlied: MostAwesomeDude: sounds like some fun for tomorrow
Kano: like it is already tagged
MostAwesomeDude: airlied: Well, have fun. I get to fight with the RS block now.
airlied: Kano: tagged where?
Kano: well in the makefile
airlied: we do that after every release
Kano: or what is 184.108.40.206
airlied: that is just so we know pepople are running a git tree
airlied: and not the 6.11.0 release
Kano: any changes expected in the near future, like today
airlied: as I said earlier we don't sit on patches waiting, Alex will probably do something when he starts work and gets some time
Kano: when does he start?
airlied: no idea, I suppose when he starts answering questions on irc
airlied: mo3sizlak: if you want to try my drm-next branch of drm-2.6 it might help narrow it down
bschindler: Hi - When I plug an external monitor to my laptop, the auto-refresh selector seems not to work too well - the image is quite fuzzy, however, no other refresh rate is selectable.. could this be a bug?
bschindler: the screen is connected via vga, and the xrandr-output is here: http://rafb.net/p/bmwdJw46.html (Note, when the screen becomes fuzzy, 1600x1200 is selected, unlike in the paste)
TobiasTheCommie: the 6xx-7xx branch is just exa and xv acceleration, right?
TobiasTheCommie: as in, no opengl, no kms, no gallium.. just straight mesa exa and xv?
TobiasTheCommie: oki, thought as much :)
MostAwesomeDude: Even if those existed, they would be in branches on mesa/mesa and such.
TobiasTheCommie: oh, hm, didn't know that..
TobiasTheCommie: as it is now r300-500 are being ported to kms right? or gallium? or both?
MostAwesomeDude: Since all the Gallium/Mesa code is in mesa/mesa and not in the DDX.
MostAwesomeDude: There's KMS for all Radeons, although there's no DRM+KMS for r6xx+.
TobiasTheCommie: i didn't think gallium was in the mesa code..
MostAwesomeDude: And there's Gallium WIP for r300-r500.
TobiasTheCommie: so wait, is there kms without drm for r6xx+?
arekm: wonders if kms for r300 is still doing "black screen" and oops
TobiasTheCommie: because that would be cool, i just didn't expect it.
MostAwesomeDude: TobiasTheCommie: Yes, there is. It's not doing much though.
MostAwesomeDude: arekm: It shouldn't.
TobiasTheCommie: still nice
bschindler: is radeon (r300-r500 I suppose) kms planned for merging in 2.6.30?
MostAwesomeDude: Not AFAIK, but then again I'm not the maintainer.
valgaav: Oh I see some devs around Hi there :)
valgaav: I have a Turion laptop with rs690 card ... is it normal that compositing and/or EXA work without corruption only when CPU scalling is set to performance (1700Mhz) ?
MostAwesomeDude: No. In fact, that sounds very weird.
valgaav: on the other hand when it's set to "on demand" I get many flashes and grphical corruption
valgaav: so I should report a bug ?
valgaav: I tried this on many distros both compiz and kde4 kwin
MostAwesomeDude: Wait, you say "and/or EXA?" So EXA only still results in corruption?
valgaav: less noticable
valgaav: but still I can notice it
MostAwesomeDude: Hm. Which version of xf86-video-ati, which kernel version, do you have a screenshot?
valgaav: right now I'm at work so no screenshots sorry ...
valgaav: I'm running jaunty right now so it' newest video-ati and newest stable mesa
valgaav: 2.6.28 kernel
valgaav: had the same thing in interipid
valgaav: and the same when when running X from ubuntu-edgers repo .. should be close to current svn
MostAwesomeDude: Well, git, but yeah.
MostAwesomeDude: Could you describe the corruption?
valgaav: well it's a bit like tearing I guess
valgaav: a bit like jumping screen
valgaav: because soem elements of the desktop tend to just for a second apear a bit higher then they should
valgaav: also white
valgaav: english is not my main language so I hope it's a nice description
valgaav: I could try to make some pictures of the screen at home ... and provide xorg.log latter
MostAwesomeDude: Sounds like bandwidth problem, although I'm not very good with modesetting.
valgaav: so I should wait for airlied or agd5f ? :)
MostAwesomeDude: agd5f would know it. He's far more awesome than I.
valgaav: well in my not so good understanding I blamed dri and decided to wait for dri2 :P
valgaav: but by accident I set the laptop mode to performance and started 3d effects
valgaav: and it was working ok
agd5f: valgaav: weird. never heard of that before.
valgaav: it should work fine then I guess ?
valgaav: ok so I should report a bug then ?
valgaav: please tell me what I attach to it to make it helpfull
valgaav: xorg.log ... some screens ?
agd5f: xorg log, config, dmesg
agd5f: picture of the problem if you can get it.
valgaav: dmesg | grep with some magic word ? :D
agd5f: not sure what to look for off hand. might be gpu related, might not be
valgaav: dmesg | grep drm or something like that ?
valgaav: ahh ok :P
valgaav: picture will be hard to get but I will try
agd5f: could be a bug in the cpu scaling code
valgaav: I tried to set it to just 800 mhz all the time
valgaav: the problem was still there
valgaav: I also disabled acpi in the kernel
valgaav: didn't help
stuckey: I'm trying to use a radeon 9600 card with the free radeon driver... The x server is failing to load. It says, "failed to initiatiate core devices" and following with several line of output which start with "(**)RADEON(0)" Anyone know why this might be?
agd5f: stuckey: pastebin your full xorg log
stuckey: agd5f: Is there another way I could do this, the computer isn't networkable...
agd5f: stuckey: does vesa work?
stuckey: agd5f: Hmmm... not sure, but yeah let me see if I can burn a cd or something with that output on it... I should post it.
Fisiu: can I run tvout on Radeon Mobility X700 with radeon driver?
agd5f: Fisiu: not at the moment
Fisiu: xrand shows I can't...
Fisiu: any chance to get it working in near future?
agd5f: Fisiu: I won't have time to look at in the near future unforunately
stuckey: agd5f: http://paste.debian.net/29023/ and http://paste.debian.net/29022
Fisiu: I can't code it myself, but is there anything I can do what can help
agd5f: stuckey: looks like an input issue. you might try on #xorg
stuckey: agd5f: what's an input issue?
Fisiu: or kbd
agd5f: can't find your mouse
stuckey: agd5f: strange...
agd5f: (EE) xf86OpenSerial: Cannot open device /dev/mouse
agd5f: maybe you changed the symlink
stuckey: agd5f: Yeah but it's showing the errors about radeon when it fails... not about a mouse.
agd5f: those aren't errors
agd5f: the xserver didn't start, so the driver is cleaning up
agd5f: stuckey: (WW) No core pointer registered
agd5f: Fatal server error:
stuckey: I see
Fisiu: starox__, give us output "ls /dev/input/"
Fisiu: sorry, I mean stuckey
Fisiu: stuckey, wrong device in [Option "Device" "/dev/mouse"]
enouf: might even want Option "AllowMouseOpenFail" Yes as a quickey workaround
agd5f: osiris_: hey, I just pushed rs600 support to drm and ddx. it's completely untested
bgoglin_: agd5f: did you see my question about load_detection yesterday ?
agd5f: bgoglin_: just saw it
agd5f: bgoglin_: is it just xserver 1.6?
bgoglin_: agd5f: I haven't tested everything myself. it worked a long time ago. I was told it broke when upgrading from Xserver 1.5+radeon 6.10 to 1.6+6.11. On my X300, both 1.6+6.10 and 1.6+6.11 break for me. so i guess xserver 1.5->1.6 caused the problem
bgoglin_: can you reproduce some problem on your side?
agd5f: I'll take a look later today
bgoglin_: ok thx
agd5f: bgoglin_: do any other output attribute have problems?
agd5f: or just load_detection?
bgoglin_: I don't have my radeon here, I'll check within 2h and let you know
agd5f: bgoglin_: thanks
spstarr_work: looks at git
spstarr_work: yep, airlied's been busy
valgaav: Agd5f are you there ?
agd5f: valgaav: yeah
valgaav: I have the files you asked ... should I paste bin those here od just report a bug on freedesktop.org
valgaav: also about the screenies I have a video with the problem
agd5f: valgaav: file a bug and attach them to the bug
valgaav: thanks for help
agd5f: valgaav: np
bgoglin_: agd5f: tv_standard works fine. load_detection doesn't appear in xrandr --verbose at all
bgoglin_: agd5f: but it appears for VGA-0. so there's something specific about S-video
bgoglin_: (it appears and can be changed)
agd5f: bgoglin_: fix pushed
bgoglin_: ok testing soon
bgoglin_: agd5f: it works! you're so fast :)
agd5f: bgoglin_: :)
rnoland: adamk: ping
adamk: rnoland, pong
spstarr_work: * Mon Feb 23 2009 Dave Airlie
spstarr_work: - radeon: merge radeon-rewrite branch, drop old r300 bufmgr
spstarr_work: thanks aseigo i will begin testing tonight!
spstarr_work: airlied :)
kkuno: great agd5f, rs600 support :D
kkuno: I will test it today
agd5f: kkuno: cool. thanks
valgaav: lol airlied was miastaken for aseigo :D :D :D
airlied: spstarr_work: I have some more patches to push on top of it, DRI2 is still a bit unstable though.
spstarr_work: airlied: that's ok
spstarr_work: this is with kms off right?
airlied: dri2 is kms on only
valgaav: any chance for radeon kms/gem to hit 2.6.30 ?
glisse: i think it's not ready
mattst88: 2.6.30 is a long way off, glisse. Do you think it needs _that_ much more work?
glisse: mattst88: iirc feature add are only accepted few weeks after previous release
glisse: and i think 2.6.29 release is imminent
mattst88: ahh, that is true
glisse: that said i think it won't even be ready before 2.6.32
glisse: of course i hope it gets in before
valgaav: that's like almost 2010 :P
glisse: and if i find time i will work on outstanding issue
glisse: valgaav: airlied is pretty much alone working on it
glisse: that's not much people
spstarr_work: airlied: right now kms does not get enabled for r3xx right? since its falling back to text
arekm: so we'll have to wait until 2010 ;(
valgaav: well no hurry ... I'm quite happy with XAA and the recent Xvideosync patch :)
valgaav: really that "no more tears " patch IS great :)
spstarr_work: but i have real tears, kwin is adding all these nifty effects and i cant use 3D ;-)
valgaav: me too :P
valgaav: if you mean compositing that is
spstarr_work: valgaav: well, we should have better radeon 1/2/3 drivers soon
arekm: that's why I choose new notebook with dual gpu - intel and ati (aka switchable graphics)
spstarr_work: a long winding road, but the road becomes multi-laned soon :)
arekm: to be able to use what's better at a time ;>
valgaav: would be nice to run some 3d effects on my rs690
valgaav: oh well I shouldn't be greedy ....
valgaav: remembers the times he was using fglrx
valgaav: radeon rocks :P even without 3d :P
adamk: Was the atom-tvout branch merged into the main tree?
airlied: adamk: yes a while back
airlied: oh wait I forget
airlied: yes it just needs an option to enable
adamk: Someone on the freebsd forums was asking about tv-out with his HD2400.
adamk: Do you remember the option?
adamk: ATOMTvOUT :-)
airlied: thats the one.
PuffTheMagic: when i switch VT's it crashes my xorg
PuffTheMagic: is there a bug I dont know about?
mo3sizlak: well newest f10 kernel seesm to have fixed compiz random lockups
mo3sizlak: now it wont wakeup from suspend to ram
mo3sizlak: i get a bunch of random garbage on screen and its hung
TobiasTheCommie: wow, there are a lot of people in here suddenly
TobiasTheCommie: doesn't help me find the red hat guy i'm lokoing for...
moeSizlak: i take it back, i *DO* still get random locks w/ newest f10 kernel
PuffTheMagic: does anyone knwo why Xorg crashes when I switch vt?
moeSizlak: radeon driver
PuffTheMagic: yes with xf96-video-ati
moeSizlak: no, that was my answer
PuffTheMagic: well thats hardly an answer
PuffTheMagic: something in xf86CrtcSetModeTransform
PuffTheMagic: ahh i think it was cause i had swcursor on by accident
moeSizlak: well once you figure that out see if you an fix the bug that causes my pc to randomy lock when i use compiz
soreau: Would anyone happen to know if there is a bug report for compiz blur effects and mag->fisheye mode not working (falls back to sw rendering) or where I should look for one? If there isn't one already I'd like to file one
airlied: file one I suspect we don't jhave one
soreau: Where is the recommended place to file?
soreau: airlied: Thanks
spstarr: well, today's kernel kms was on, vt switching that locked up though
spstarr: yums up
rnoland: agd5f: heh, i just cut the patch for r6/7xx last night/this morning... i guess i get to make a new one....
spstarr: oh, my rawhide didnt have today's mesa + ddx + kernel updates
TCW: Hi folks... how is rv6xx support these days? I see in the topic "not yet", any clue about the near future?
airlied: TCW: its in a development branch
airlied: just video + 2D accel
TCW: airlied, I am especially interested in xv and 3d (dri?)
airlied: TCW: no 3D yet
TCW: airlied, a guess in the not-so-blue when it will support 3D?
airlied: TCW: not sure, AMD are working on getting a shader compiler released
rnoland: when it's done? ;)
airlied: when they get that through code review is anyones guess.
airlied: I'd say a few months before we get something approaching what we have now for other cards
TCW: It is like always... new computer, will it be ati or nvidia... fglrx is (very very often) crap, nvidia works (most of the time) flawlessly... but the idea to have open drivers is VERY nice, indeed... but I don't want to recommend a gfx card and waiting more than maybe a few months to get eye-candy wobbly-wobbly with Linux...
TCW: it is for a friend of mine, he wants to watch video and I want him to have a very nice 3D-Linux experience :)
pepperjack: im building an htpc and only care about 2d performance for hd movies. is there a specific chipset i should look for on the MB right now?
airlied: damn clear state
kcodyjr: hm. wonder if that's an isp going down, or a server going down
airlied: glisse: any memories of the CP just going crazy and sending single reg streams to random other plaecs?
airlied: glisse: ^ is cmdfifo dump looks a bit crazy
benh: airlied: did you ever see the same lockups as I see on Bimini with the G5 ?
benh: needs to get up to speed with dumping indirect buffers & cmd fifo
benh: I wonder if it could be something specific to the bimini, ie a bridge badly configured or such
airlied: benh: I think I got them the last time I played with it.
airlied: but memory hazy.
airlied: benh: drm-rawhide branch has ring and ib dumpers in it
airlied: avivotool has a fixed cmdfifo dump
airlied: the ib dumper is probably tied to kms though :(
benh: airlied: does it have davem and I fixes too ?
benh: hrm... ok
benh: well, I suppose I can hack something together
airlied: benh: not yet its need rebasing on top of drm-next
benh: oh well, we'll see when I manage to hack on that