spstarr: airlied: im going to be forking kwin locally and ripping out all of it's composite initialization and redo it, well try
spstarr: maybe i can make it follow compiz's initialization
spstarr: remove shm, indirect rendering, fallback, XRender
spstarr: this is going to get painful, very fast ;)
airlied: I doubt its the init code
airlied: more likely some of fbconfig or virt code
airlied: or the blending on the TFP stuff
spstarr: well they use different extensions
spstarr: besides XDamage, XComposite and XShape
spstarr: fbconfig.. hmm l
airlied: its more likely the GL stuff than the X side
spstarr: then that would be the scene_opengl.cpp code
airlied: some of the visuals/fbconfig/TFP params.
MrCooper: what's the issue, still that weird corruption?
spstarr: airlied: they also have double buffer drawables
spstarr: i just care about kwin using TFP
spstarr: and gut the rest
MrCooper: does it happen with current upstream master of DRM, xf86-video-ati and Mesa?
spstarr: well my DDX is...xorg-x11-drv-ati-6.12.0-2.fc11
spstarr: DRM is 2.4.5
spstarr: mesa is 7.5 + radeon-rewrite from airlied as of today
spstarr: drm is whatever is in fedora rawhide kernel
MrCooper: so does it happen with mesa master?
spstarr: no new changes from airlied
spstarr: well airlied merged mesa master with radeon-rewrite so, yes
spstarr: in his branch
MrCooper: ugh no
MrCooper: he merged master to radeon-rewrite, not the other way around
spstarr: yeah into his branch
spstarr: but mesa 7.5 is currently what master is?
nanonyme: As in merge pulled new changes from master to radeon-rewrite?
MrCooper: master is master
MrCooper: if radeon-rewrite was the same thing, it wouldn't need to be a separate branch, would it
spstarr: is 7.5 + his patch is what is in rawhide, do you want me to try to build mesa git master?
spstarr: that wont have the rewrite code
spstarr: unless i can patch that in
spstarr: if i modify this to follow how compiz sets up GL visuals/buffer maybe i can get this to work
spstarr: they just do too many things in kwin, who cares about SHM fallback and XRender, we want TFP only
spstarr: i have a lot of code to gut
MrCooper: note how I asked for 'master', not 'radeon-rewrite' or 'master patched with random stuff'...
spstarr: i have not tried master, no
spstarr: MrCooper: is there something in git master that might help?
MrCooper: note the 'rewrite' in radeon-rewrite, rewrites tend to introduce regressions
spstarr: oh quite possible
spstarr: but if it works with compiz and not kwin...
MrCooper: I haven't seen it with kwin either
spstarr: on r3xx agp?
MrCooper: anyway, it would just be another data point which might help narrow it down, k?
spstarr: but isn't the mesa drivers in mesa only for DRI 1? I thought the radeon-rewrite code was to support DRI2 + hook up the new mm
spstarr: so compiz supports dubble buffer fbconfigs
MrCooper: yeah, I wasn't aware it only happens with DRI2...
spstarr: DRI 1 i didnt have that kind of corruption with kwin, it did work, just locked up often
spstarr: but i never tried in months prior to DRI2
MrCooper: might still be worth trying it then
spstarr: i suppose i can grab master, and build it as an RPM
spstarr: comment out all the patches in rawhide and test
spstarr: but turn off kms
spstarr: I do notice that kwin and compiz setup their buffers differently
spstarr: kwin also 'chooses' which destination buffer type
spstarr: based on visual/depth
spstarr: i wonder if its picking the wrong one altogether
spstarr: glxinfo says there are 64 GLX visuals
spstarr: maximum depth 24 and one 32
spstarr: 96 config frame buffer visuals for GL
spstarr: i dont follow what those do
spstarr: found where the copied compiz's setup of fbconfig
spstarr: some of it looks ripped right out :)
spstarr: compiz lumps it all in screen.c addScreen()
spstarr: kwin adds:
spstarr: glXGetFBConfigAttrib( display(), fbconfigs[ j ],
spstarr: GLX_RENDER_TYPE, &value );
spstarr: i'll gut that in my code
spstarr: and gut those that aren't matching compiz's setup of fbconfigs
spstarr: but glxGetFBConfigAttrib() is just reading a property not changing it
spstarr: so i guess that code doesnt really do anything
spstarr: not that we care about
Zarin: I wonder why Compiz and KWin get the initial FBConfigs the way they do. I've done it a different way using glXChooseFBConfig()
spstarr: you'd have to ask david why he did it this way
nanonyme: Maybe he'll just answer it's his way or the highway?
Zarin: Just pass it a pile of attributes and it spits out the best one, currently Compiz and KWin iterate over every single config, check their attributes, then choose based on that
spstarr: so far SceneOpenGL::initDrawableConfigs() is matching compiz
spstarr: aside from the extra query kwin does
spstarr: except caveat
spstarr: this is not in compiz
spstarr: this attribute defines any problems that the GLX FBConfig may have
spstarr: and returns GLX_NONE, GLX_SLOW_CONFIG, GLX_NON_CONFORMANT_CONFIG
spstarr: i will for sure comment this out or print out the return
spstarr: end function
spstarr: i dont even know which GL visual kwin wants to use
spstarr: sleep for now, 4am, i'll bash this in the day
Zarin: spstarr, hangon
spstarr: ok one sec...
Zarin: I have a commented version of the init code
spstarr: its putting laptop to sleep..
spstarr: or i did :)
Zarin: lines 326+
Zarin: It's based off the KWin one, I dunno what I've changed
Zarin: But it should be easier to read
Zarin: The code itself doesn't work, but that doesn't matter for you :)
spstarr: it looks cleaner
spstarr: maybe i should steal your code and replace kwin's bits with it ;P
Zarin: If you're going to do that you might as well use the later version of Aethis
Zarin: Lines 150-180
Zarin: Much less code
spstarr: why not just blow up kwin instead of a another wm/compositor?
Zarin: I'm writing Aethis to learn, not to make a product
spstarr: but kwin isn't a product, its just as free to play with
Zarin: Writing from scratch copying absolutely nothing from other programs makes you learn faster :)
Zarin: Well it does for me anyway
spstarr: as far as i can see, aside from the caveat check the setup of picking which GL visual to use seems to be the same
spstarr: from compiz / kwin
spstarr: from there it diverges on GL
spstarr: oh airlied
spstarr: airlied: do we have vblank/vsync in DRI2?
spstarr: is it possible the reason the window contents aren't being shown is because kwin isn't seeing any vblank?
Zarin: Disabled vsync mode in KWin then?
spstarr: i thought I did
spstarr: no different, i am seeing no window at all, unless i drag it then i can see it for a moment until i release mouse
spstarr: oh not even that now, its totally hidden
Zarin: Is this with any effects enabled?
Zarin: Enable transparency if everything is disabled, if that doesn't work try wobbly
spstarr: no effects at all enabled
Zarin: KWin follows a different code path when the window is transparent or transformed
spstarr: kwin did not like indirect rendering failed to even let me cancel it (it reverted to direct rendering)
spstarr: ok trying transparent plugin
twoerner: airlied: ping
spstarr: yes, if i have wobbly i can see the window while dragging it
spstarr: releasing the window by moving mouse away it then gets corrupt
spstarr: or vanished
spstarr: wow that is 40% better
spstarr: still not usable for normal env
spstarr: Zarin: enabling wobbly i can see the windows, but they will vanish if i click elsewhere
spstarr: so there's some sort of repainting going on
spstarr: ok direct or indirect rendering make no difference, they both dont show the windows
spstarr: Zarin_: is there kwin debug mode?
spstarr: so i can see what it does in events?
spstarr: maybe i can narrow which routine is causing paint problems
spstarr: since i am seeing wobbly windows with kwin and smoothly
spstarr: kwin(3576) KWin::SceneOpenGL::initBufferConfigs: Drawable visual (depth 24 ): 0x "e6"
spstarr: kwin(3576) KWin::SceneOpenGL::initBufferConfigs: Drawable visual (depth 32 ): 0x "57"
spstarr: kwin(3576) KWin::SceneOpenGL::initBuffer: Buffer visual (depth 24 ): 0x "e8"
spstarr: kwin(3576) KWin::SceneOpenGL::SceneOpenGL: DB: true , TFP: true , SHM: false , Direct: false
spstarr: kwin(3576) KWin::Workspace::setupCompositing: Refresh rate 60 Hz
spstarr: ok so it dumps it out
spstarr: huh it's using indirect even though i told it direct?
spstarr: Zarin_: bingo?
spstarr: it is failing to use Direct Rendering
spstarr: kwin(3576) KWin::SceneOpenGL::SceneOpenGL: DB: true , TFP: true , SHM: false , Direct: false
spstarr: direct rendering: Yes says glxinfo
spstarr: is this determined by a glxfbconfig?
spstarr: wheither to use indirect or direct?
spstarr: Zarin: i think i found something
spstarr: kwin(3576) KWin::SceneOpenGL::SceneOpenGL: DB: true , TFP: true , SHM: false , Direct: false
spstarr: it refuses to use Direct rendering?
Zarin: I missed everything after "
Zarin: By the looks of things yet
airlied: MrCooper: twoerner pong
airlied: twoerner: poong
spstarr: transparent windows i can see the window unless i lose focus then it goes blank
peterz: airlied: [123207.068474] [drm] wait idle failed status : 0xA0003030 0x00000003
peterz: airlied: tons and tons of those,..
spstarr: Zarin: how do we determine indirect/direct render?
twoerner: airlied: i am using the GIT driver since two days now and there are no problems
Zarin: spstarr, the falling back is a part of glXCreateNewContext()
Zarin: spstarr, ctxbuffer = glXCreateNewContext( display(), fbcbuffer, GLX_RGBA_TYPE, NULL, direct_rendering ? GL_TRUE : GL_FALSE );
twoerner: airlied: the system is up since two days and no Xv usage is resulting in a oops
Zarin: Then KWin uses glXIsDirect() to see if it really is direct
spstarr: airlied: is it easy to write a simple program to determine if its using direct render?
spstarr: Zarin: hmmmmm, then something is lying :)
spstarr: cause we're supposed to be direct rendered now not indirect for DRI2 (by default)
airlied: peterz: does anything break or stall?
airlied: spstarr: no we keep using indirect
peterz: airlied: yeah, X died over-night, and am now locked out of the console
Zarin: spstarr, Ah, did you start KWin with "KWIN_DIRECT_GL=1 kwin --replace" ?
spstarr: airlied: still? :/
spstarr: Zarin: lemme try that
peterz: airlied: machine is sorta still running, but X is badly hogging a cpu
airlied: at least compiz direct rendering has some damage issues
airlied: peterz: yes the GPU is hung, that with the drm-nxet branch?
peterz: airlied: yes, tip+drm-next
airlied: can you file a bug against xf86-video-ati, as Alex might know where its going wrong
spstarr: Zarin: its spitting out
peterz: airlied: sure, what info do I include?
airlied: did a screensaver or anything kick in?
spstarr: settexbuf 1000x313@4 4032 targ 84f5 format 1401
spstarr: whats this coming from
peterz: airlied: if so, I have a simple blank screensaver
airlied: peterz: /var/log/Xorg.0.log and an abstract from the dmesg
airlied: spstarr: mesa prints it out
spstarr: and other settexbuf
airlied: spstarr: its my debugging
spstarr: anything in that that might be useful for you?
airlied: spstarr: granted direct renedered still draws window contents at least, just text garbage
airlied: not really its just for debugging compiz
spstarr: im not seeing text garbage with kwin and it
spstarr: but the windows are still vanishing
DanaG: Too bad hung GPU makes Xorg eats CPU, instead of just hanging with 0% CPU usage.
airlied: DanaG: you have to keep asking it if its ready yet :)
Zarin: spstarr, I'm surprised you can even get KWin to run that far... I wonder how the self-check passed if you can't see anything
DanaG: Extra bit of code: if the GPU hasn't responded in, oh, say, a full minute, then deliberately kill Xorg instead of continuing to devour CPU.
Zarin: The self-check creates a new window, renders it, then reads the pixels back out of the output buffer
DanaG: I don't think any valid operation should ever take a full minute, should it?
DanaG: goes off to bed. It's 1:43am.
rvalles: [ 672.179537] [drm] Loading RV770 CP Microcode
rvalles: r770 xv & exa seem to be fine :)
spstarr: ok, im gonna try mesa from git master and see what happens with kms off
airlied: spstarr: I think DRI1 will work fine
spstarr: i can use that for now until things are ready
MrCooper: spstarr: is there supposed to be a specific effect in the cases when it happens, e.g. making the window translucent or something?
spstarr: in my case i had no effects on
spstarr: just toggle composite on
spstarr: MrCooper: although in more recent DRI2 now i dont even see window frame like before in that video, it just draws updated areas that are damaged
spstarr: ie, if a tab in xchat turns red, it redraws just that tab
spstarr: or if someone types it redraws the text box in xchat, etc
spstarr: but not the whole window contents or any other windows
spstarr: ./make-git-snapshot.sh master
spstarr: building mesa master RPM
spstarr: i suppose I should --disable-gallium in %configure line :)
spstarr: we dont build gallium yet
spstarr: oh it is
nanonyme: spstarr: Gallium core and apparently Intel Gallium is autoenabled in Mesa Master.
spstarr: even with --disable-gallium ?
nanonyme: Well, that not. :)
spstarr: its building the DRI drivers right now...
nanonyme: I thought you meant you thought it's defaulted to disabled - which it is not.
airlied: spstarr: in theory turning off kms gets you clsoe to master
airlied: if it works with kms off, then its DRI2 related
airlied: if it doesn't work with kms off then you could check master
spstarr: lemme try it now before i swap RPMS
spstarr: lemm ewait til the RPMs are built then incase it locks up
spstarr: 7.5-0.8 for gap
spstarr: success building.. now to try with existing rpms 0.5
spstarr_home: fails, goes black, then i cant do anything
spstarr_home: trying new mesa
spstarr_home: master works
spstarr_home: airlied: odd.. if i use git master kwin works
spstarr_home: no kms of course
spstarr_home: vt switches
spstarr_home: a little corruption
spstarr_home: but it didnt lock up!!!!!!!
spstarr_home: airlied: looks like i found a temporary home in git master :)
spstarr_home: turns on effects
spstarr_home: hmm X is using 60%
spstarr_home: i suppose putting back my xorg.conf will do sincei had some config options
monreal: Hi #radeon. I need a replacement AGP graphics card for my sister's oldish PC (Athlon XP around 2GHz). It should be supported by a free driver and by supported I mean it should work stable and provide 3D functionality. Would R500 cards (X1650, X1950) be reasonable for this?
adamk_: monreal: Sure.
adamk_: monreal: Well, it depends on the 3D functionality you want, but assuming it's not too complicated, it should work.
monreal: mainly tuxracer :) maybe some desktop effect stuff
adamk_: Yeah, an r500 would work just fine.
taiu: MostAwesomeDude: does this look right? memcpy(&r300->vertex_info, &vinfo, sizeof(struct vertex_info));
taiu: r300->vertex_info is of type r300_vertex_format
monreal: the R500s will also "soon" support DRI2/KMS stuff?
stikonas: monreal: yes, it is already working in Fedora Rawhide
adamk_: Well, I know it's being worked on.
rvalles: wondering... if I went and built mesa head, would I get gallium3d softpipe?
rvalles: I'd take that over old softpipe.
airlied: why? its not as fast as the old one
MrCooper: airlied: depends what for... especially with LLVM :)
osiris__: airlied: FYI your last patches didn't fix fbo firecube. I also tried glean/fbo but it hardlocked machine (even sysrq didn't work). tests/fbotexture almost works - it looks to me like missing depth clear (new frame is drawn on top of previous)
MrCooper: osiris__: fbotest1/2 work?
osiris__: MrCooper: yes
airlied: ossman: iwerd on my rs690 it all seesm fine
airlied: like firecube is slowwww
MrCooper: fbotexture can be a little tricky as it also uses stencil
airlied: but if I set texType to 7 by hand it works fast
MrCooper: rvalles: with the right build configuration you should be able to build both at the same time
osiris__: airlied: FWIW when running fbo_firecube I get many 'no rrb' errors
MrCooper: though probably the simplest way to build Gallium softpipe/xlib is something like 'scons dri=0 drivers=softpipe #debug=1 llvm=1'
airlied: osiris__: sounds like the sw fallbacks
airlied: osiris__: I'm thinking of chaning command emission
airlied: so we don't submit state unless we have some vertices emitted
rvalles: MrCooper: thanks
airlied: at the moment we seem to have some cases where we get some state emitted but never push out any vertices
rvalles: that means I can't just count on gentoo's ebuild doing it right
airlied: osiris__: if you set texType = 7 in fbo_firecube.c
airlied: does it do anything different?
rvalles: it probably won't hurt to try however
rvalles: after all, it takes some 10 minutes at most
osiris__: airlied: yeah, I've faced it during OQ hacking
rvalles: as to mock me, there's a "gallium" use flag.
osiris__: airlied: it works with texType=7
airlied: osiris__: so it sounds like some sw fallback issue, maybe failing to setup something in that case
osiris__: airlied: also when I try to change textype during app run when it hits texType = 7 it crashes with 'CS section size missmatch start at (r300_cmdbuf.c,emit_tex_offsets,186) 4 vs 2'
osiris__: airlied: and '[drm:radeon_cs_relocate_packet0] *ERROR* Packet 3 was 1160 should have been c0001000: reg is 4540' in kernel
airlied: okay I only get no rrb
airlied: what is the git commit of radeon-rewrite you are using?
osiris__: airlied: 8ed405cd371 radeon/r200/r300: set correct row stride for rbs
airlied: osiris__: wierd.
krigstask: Hello everyone
krigstask: Should /dev/dri/* devices be created for r6xx-cards?
krigstask: I have DRM/Radeon modules compiled and loaded
krigstask: That goes for kernel DRM of 2.6.28 and .29
taiu: not in stock kernels yet
krigstask: And for external modules?
krigstask: x11-base/x11-drm in Gentoo
krigstask: From dri.fourceforge.net, I believe
krigstask: Moreover, I'm uneasy about
krigstask: % dmesg| grep drm
krigstask: [ 25.329327] [drm] Initialized drm 1.1.0 20060810
taiu: dunno, the drm bits must be from from r6xx-7xx branch of mesa/drm or from drm-next branch of airlied/drm-2.6
mzz: last time I checked x11-drm was not your friend (just use a current kernel instead)
mzz: (and for this stuff you need something more recent than that)
krigstask: mzz: when did you try it?
mzz: ah, there's actually a more recent x11-drm now.
mzz: still, in general I'd try in-kernel drm before x11-drm
mzz: (and in this case you need something more recent than either, see above)
krigstask: I've got 20090320 version
krigstask: I've tried both
krigstask: So you're saying I just have to wait?
mzz: I'm assuming taiu knows what he's talking about, in which case you'll almost certainly need to actually pull that from git
mzz: there may be a live or snapshot ebuild out there somewhere, but I seriously doubt it's in portage
krigstask: mzz: thank you
krigstask: I think I understand now
krigstask: I'm quite happy with current situation as far as it's normal
krigstask: I just wanted to know if versions I have tried are capable of smth more
mzz: (as for x11-drm: if you look at the ChangeLog for that package you'll see there's only about one per year)
mzz: (since kernel releases are more frequent than that I'm assuming that means you're behind a lot of the time using that)
krigstask: All right
krigstask: But why dmesg tells that I have drm of 2006 ? (see above)
krigstask: Am I missing something?
krigstask: Does your drm module report another version?
taiu: no, you aren't missing anything:) that date seems static
krigstask: Thanks for info
krigstask: mzz: as for kernel DRM vs. x11-drm, there's lots of talking about old kernel modules and hot-from-git x11-drm
krigstask: Now I'm unsure (-:E
edt: krigstask you need to follow the instructions at: http://wiki.x.org/wiki/radeon:r6xx_r7xx_branch
edt: to get exa working
edt: with gentoo
MrCooper: the problem is that R600 support hasn't been merged to drm.git master, not sure why
krigstask: edt: I think I've got it working
krigstask: The difference between 6.12 and 6.11 are dramatic
edt: here it works pretty well - only one program i found that does not display 100% correctly and that might not be due to drivers
krigstask: I just want to set everything up and upgrade drivers as they grow in version
krigstask: I thought I should have something in /dev/dri/ , even if fancy stuff like 3D accel etc doesn't work at the moment
krigstask: edt: about your link: it's merged in xf86-video-ati 6.12, isn't it?
nanonyme: You should have that, yeah.
nanonyme: (That is, with the r6xx-r7xx-support drm branch)
krigstask: nanonyme: I'm not sure if it's merged into drm modules I use
krigstask: I mean r6xx-r7xx support
krigstask: But 2D acceleration works
nanonyme: It does not work without r6xx-r7xx-support branch of drm or drm-next branch of kernel.
nanonyme: That is, EXA.
nanonyme: EXA requires DRI on the new chipsets.
nanonyme: krigstask: Which drm modules are you using?
krigstask: I've tried kernel modules of 2.6.28 and 2.6.29 and separate modules, dated of 2009-03-20
nanonyme: Kernel modules in 2.6.28 and 2.6.29 are too old.
krigstask: I think so
nanonyme: 2.6.30 is the first one that's new enough.
krigstask: nanonyme: which distro do you use?
nanonyme: Debian. How so?
krigstask: I just wonder how is gentoo package built
nanonyme: I don't use packages.
nanonyme: Follow the guide edt gave.
krigstask: nanonyme: I understand this, but I'm quite happy with current situation
krigstask: So if I'm not dumb and all the packages I have are too old I think I'll just wait then
krigstask: Thank you for info
nanonyme: krigstask: You said that you don't have /dev/dri so you don't have Xv or EXA. If you're satisfied with that, fine.
krigstask: nanonyme: as far as it's normal, I am
nanonyme: It means more CPU usage for eg video playback but yeah, I guess you can say it's normal. :)
krigstask: nanonyme: I mean, if that's packages that are old, not me being too dumb to configure everything properly (-:E
krigstask: I've got your point there
krigstask: Another dumb question: r6xx/r7xx support hasn't been merged into x11-drm mainline?
krigstask: Or I misread the guide?
nanonyme: You did.
nanonyme: krigstask: r6xx-r7xx-support has been merged to master in xf86-video-ati, not drm.
krigstask: nanonyme: yes, but I'm talking about drm modules
nanonyme: krigstask: I answered your question.
nanonyme: Read my answer again.
nanonyme: In a simple form: No, it hasn't been merged. Yes, you read it wrong.
krigstask: That's what I've said, isn't it?
krigstask: So I have to build drm modules from separate (for now) branch?
nanonyme: Forget it, I'm just being dumb and apparently also a prick.
nanonyme: You got it.
krigstask: All right then, thanks for patience (-:E
nanonyme: Hope you have luck getting it to work.
doncarlos: hm, what was that? something with the connection?
chithead: doncarlos: that is called netsplit, see the global notice that you just received
doncarlos: chithead, ah, thanks. i'm new to irc :)
AStorm: is there any timeline or status on KMS?
phercek: I have an xorg.conf which works well with radeonhd (static dualhead/xinerama configuration, no need to use xrandr to enable the second monitor); but this xorg.conf does not start in xinerama mode when I replace radeonhd driver with radeon driver; is there some page how to make xinerama work with radeon driver using static randr configuration like radeonhd does it? ... so that I can have almost the same config for both radeon and radeonhd
phercek: or any exaples/wiki how to make radeon driver work with active xinemara?
adamk_: phercek: Monitor identifiers are completely different between the two drivers.
adamk_: Other than that, the same xorg.conf should work.
phercek: the card is RV670PRO [Radeon HD 3850]; driver: xf86-video-ati 6.10.0-1
adamk_: You can run 'xrandr' in X to see the list of outputs X is using so yoou'll know what to use in your xorg.conf file.
phercek: adamk_: by monitor identifier, do you mean this "monitor-DVI-I_1/digital" from radeonhd xorg.conf ?
phercek: damk_: ok; thanks; that should be enough for me to continue myself :)
maleadt: hi all
maleadt: I just discovered the GSoC initiative, and I was wondering if there are doable projects in here (for example some r6xx/r7xx work) for a halfway through CS student, with moderate C/C++ knowledge but no real hardware nor X.org development experience
mattst88: I'd be interested in this as well.
yangman: mattst88, maleadt: there hasn't been much radeon/radeonhd specific talks about GSoC, but the X.org ideas list is here: http://xorg.freedesktop.org/wiki/SummerOfCodeIdeas
maleadt: yangman: thanks, I've come across that page before and the idea which attracted my attention was to implement a gallium pipe driver for r600 hw I just can't estimate the work involved with that, and more importantly if it's doable in three months (2,5 if I substract my end-term exams) to get familiar with the codebase as well as finish the project.
maleadt: (insert an end-of-line after "r600 hw")
pkt: It is unlikely unless you are a *really* good coder :P
yangman: how well do you know gallium and r600 hw?
maleadt: I don't, yet. The GSoC project has fitted one month in the timeline to get familiar with everything needed, which doesn't suffice I presume :)
yangman: it's probably premature to jump into a large r600 project like that
spstarr: well, using mesa git master + kwin i have composite more or less, its not blisteringly fast but it at least works
yangman: but, talk to MostAwesomeDude
maleadt: yangmann: allright, thanks for the comments. I'm going to have a look at the other participating OSS projects and/or other X.org ideas, as both interest me and GSoC seems a good way to get involved with them.
sroland: agd5f: do you know what the red/blue/green_intensity xv attrs should do for overlay video?
sroland: agd5f: they go into RADEONSetTransform which does some calculations with them but ultimately drops those...
agd5f: sroland: don't recall. Have to check the specs
AStorm: ok, now that more people are alive
AStorm: has there been any try at KMS yet?
agd5f: sroland: looks like they were multipliers for transform
agd5f: er offsets
agd5f: sroland: maybe something like this: http://www.botchco.com/alex/xorg/color_intensity.diff
osiris__: agd5f: have you looked at this xrandr is crashing X backtrace?
agd5f: osiris__: not yet, I haven't had time to play with kms yet this week
AStorm: [VO_XV] It seems there is no Xvideo support for your video card available.
AStorm: some recent change
adamk_: AStorm: What video card?
AStorm: Mobile Radeon HD 3850
adamk_: Sounds like you don't have direct rendering enabled in the X server.
AStorm: that should be enabled automatically
AStorm: at least, it has been
adamk_: Well, unless there's a problem, of course.
AStorm: and I do have DRI true...
AStorm: I'll check the log
adamk_: Which is the point I was tryin got make.
adamk_: Check your log file.
AStorm: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
AStorm: now, why? I'll have to check
AStorm: (this is 2.6.29 augumented with drm-next among others)
adamk_: r600/r700 support isn't in 2.6.29. Not sure about drm-next stuff.
AStorm: it is in drm-next
AStorm: at least, was
AStorm: other than that, the module hasn't been loaded
AStorm: no, it was
AStorm: I'll better check the logs
AStorm: (commit log, that is)
adamk_: If I had to take a guess, it would be that you are using the 2.6.29 modules.
AStorm: that's airlied's repo
AStorm: up to this commit is in, apparently
AStorm: commit 41f13fe81dd1b08723ab9f3fc3c7f29cfa81f1a5
AStorm: but, there might be a different issue
AStorm: oh well, I can always build x11-drm
arekm: linus started merging stuff for .30
AStorm: please ping airlied to update drm-next to 2.6.29 at least
AStorm: I suspect the merge got broken ;P
AStorm: (and I didn't do it myself, so it's not my fault :> )
AStorm: ok, I blame udev
AStorm: removed the modules
AStorm: reloaded, ran udevadm settle and there the device appears
AStorm: (X that is)
AStorm: I wonder why didn't the node get created - will try a fresh reboot again later
AStorm: works great
buggs: is the suspend bug fixed?
PuffTheMagic: airlied_: ping!
adamk: airlied_, FYI, Updating Mesa to the packages you built on koji today seems to have resolved this lockup issue.
agd5f: buggs: s/r works on radeon, still seems to have issues on rhd
adamk: Hmmm.. I might have spoken too soon.
adamk: ut2004 starts up but seems to lock X (though, unlike previously, not the entire machine).
spstarr: gives up on composite for now
spstarr: kwin / compiz locks up after a period of use (firefox scrolling window)
spstarr: maybe I'll wait till Gallium 3D is ready for r3xx
MostAwesomeDude: You'll be waiting for a while. :c
tlp: how about r5xx? :p
MostAwesomeDude: r5xx is a bit further along.
adamk: driconf doesn't work with DRI2 drivers, correct? Is there something that does?
ajax: why wouldn't it?
ajax: it just writes a config file. the config file doesn't care what protocol you're using.
spstarr: MostAwesomeDude: well, 2D isn't so bad :)
adamk: ajax, Well when I start it up, it says that Screen "0" is not direct rendering capable... Applications will still read from it, though?
tlp: will be excited when Wine finally works
ajax: probably just needs to be updated to check for DRI2 too.
sroland: agd5f: yes maybe that was the intention of those intensity attribs. Not sure though if there's much point to them? Well shouldn't hurt.
agd5f: sroland: any objections to that patch?
agd5f: it seems to work as advertized
sroland: agd5f: no certainly not...
loki_666_: airlied are you here?
airlied: PuffTheMagic: pong
airlied: loki_666_: sort off
PuffTheMagic: airlied: i was wondering if your xserver-220.127.116.11-fix-core-fonts.patch patch was upstream or not
loki_666_: airlied, trying to compile drm-next for 2.6.29, but i got an error about return type of drm_get_resource_start
airlied: loki_666_: drm-next from my kernel tree?
airlied: so did you clone 2.6.29 and pull my tree into it?
loki_666_: ah no, i cloned git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git a switch to next-drm branch
airlied: PuffTheMagic: I don't think we carry that patch anymore
airlied: so I assume it got merged
airlied: loki_666_: so thats a 2.6.29-rc8 branch
loki_666_: ah, so how to proceed?
airlied: so it doesn't compile?
airlied: because I built it yesterdaay
loki_666_: nope the return type of the fct drm_get_resource_start is resource_size_t in your branch, while it's a unsinged long in the drmP.h of my kernel
airlied: did you copy over that modules or something?
loki_666_: copy what from where to where?
airlied: I'm not sure what you built, drm-next builds on its own
airlied: office &
loki_666_: ok, i build a plain vanilla (almost) kerenel 2.6.29 in its own tree (without drm/radeon)
spstarr: airlied :(
loki_666_: then i cloned your tree, swith to drm-next branch, and tried to compile the drivers/gpu/drm directory using a make -C /usr/src/linx-2.6.29 SUBDIRS='pwd' CONFIG_RADEON=m CONFIG_DRM=m
airlied: loki_666_: es that probably won't work too well
airlied: you shoulde just pull my branch into the vanilla tree
loki_666_: how do i do that (not a git expert)
loki_666_: airlied, you can leave a msg, ill check the logs tomorrow TIA
edt: The only app I miss not having the 6.12 is google earth.
l3iggs: hey everyone, i'm new here and i'm trying to get either exa or xaa working with my R580
l3iggs: my issues can be seen here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/342899
l3iggs: can anyone in here help?