Rhamphoryncus: I've got radeonhd compiled from source on ubuntu, but I conceded defeat and just used make install
Rhamphoryncus: war between the packaging system, the file system, and autotools, and the user is stuck in the middle
lymeca: Rhamphoryncus: What's the filesystem got to do with it?
Rhamphoryncus: It sets the ground rules, which are largely useless to the packaging system
TobiasTheCommie: nha: i'm sorry to say that it still trashes
nha: too bad :/
nha: but as long as my commits haven't made it worse, I'm happy enough
glisse: TobiasTheCommie: what is your setup and in which conditions does it trash ?
TobiasTheCommie: it hasn't
TobiasTheCommie: glisse: just a min
TobiasTheCommie: glisse: http://rafb.net/p/eIBewy57.html <- some random information
TobiasTheCommie: as for the trashing, it has always started while i'm using xbmc.. but then again, i'm always using xbmc...
TobiasTheCommie: i have let the computer idle all through the night, in xbmc.. and nothing has happened..
glisse: so it's random
glisse: TobiasTheCommie: it's pcie right ?
TobiasTheCommie: yes
glisse: does xbmc use opengl ?
glisse: yup it does
TobiasTheCommie: yes it does
TobiasTheCommie: glisse: i'll try to investigate it a bit more, since xbmc is a bit unstable in and off itself..
TobiasTheCommie: but still, never had this trashing with the fglrx
nha: oh wow... I just tried running OpenGL applications from within a compiz-enabled session
nha: and man, do we suck.
glisse: nha: dri2 :)
TobiasTheCommie: nha: i haven't tried that :)
nha: glisse: yes...
nha: this is the first time I've ever tried compiz
glisse: their few things nice with compiz
glisse: their is*
nha: I wonder how I can configure compiz plugins in Ubuntu
glisse: TobiasTheCommie: when it happens can you log through ssh or move the mouse ?
glisse: nha: i think there is an applet for it
glisse: in system memnu
TobiasTheCommie: glisse: ssh yes, mouse no
TobiasTheCommie: glisse: X takes an entire core and uses it 100%
TobiasTheCommie: i just recompiled my entire system to include debug information
glisse: TobiasTheCommie: well when ever it happens log in ssh and do:
nha: glisse: I read about it, but there's no applet for me :/
nha: perhaps it's related to how I had to work around the blacklisting/whitelisting logic they have
glisse: echo 1 > /sys/module/drm/parameters/debug
glisse: followed by echo 0 > /sys/module/drm/parameters/debug
glisse: and dmesg should tell you where it's spinning in look
glisse: loop
TobiasTheCommie: glisse: should i do that after it starts trashing? or before?
nha: doing it after is probably fine
glisse: after
nha: doing it before will spam your syslog with hundreds of megabytes of log entries
TobiasTheCommie: hehe ok
TobiasTheCommie: oki
TobiasTheCommie: glisse: thank
TobiasTheCommie: glisse: thank you very much
TobiasTheCommie: basically, besides for the trashing, my only problem is that FIFA08 doesn't work with the ati driver.. but then again, it doesn't work with fglrx either(does work with nvidia though)
glisse: TobiasTheCommie: well we just want to fix lockup and welcome any clue on that :)
TobiasTheCommie: glisse: and honestly, i like to try and make stuff crash.
TobiasTheCommie: as in, for a purpose, not just to make it crash
onestone: MostAwesomeDude: ping
TobiasTheCommie: someone in here were having some problems yestereday with, i think, YUV<->RGB transformation
TobiasTheCommie: i think i'm having the same thing on xv output..
TobiasTheCommie: on an rv530
nha: onestone: I'm looking at the "compiz-fusion/fisheye on r500" problem, though right now compiz doesn't work at all for me on R500
nha: it just results in a grey screen
nha: works fine with R300 though
osiris_: MostAwesomeDude: ping
onestone: nha: I haven't updated mesa for a while
adamk: nha, That's the fisheye bug I reported to you before?
kraehe: moin ... i fear i need a new pc ... and wonder ... are the new opensource rxxx drivers now compareable in OpenGL with the old r200 tungsten drivers
nha: adamk: yes
kraehe: currently has an r200 running at its limits
TobiasTheCommie: kraehe: besides for some minor instability, which is being investigated, my rv530 works better with the ati driver than the fglrx
kraehe: and I need full OpenGL 2.0 support - OpenGL 1.2 does not longer suit my needs
TobiasTheCommie: i've only really tried with xbmc, which works.. and compiz should also work
nha: kraehe: bad luck there :/
kraehe: fglrx/catalist drivers are for the trashcan, TobiasTheCommie
nha: we support OpenGL 1.3 and most of the extensions that would be needed to support OpenGL 1.5
TobiasTheCommie: nha: i thought everything but the scripting language of opengl 2.0 was implemented.. hm...
onestone: nha: bisect mesa 92c075eeb7c330ea420400d1c2bae57356b19f03 compiz is working but fisheye is broken
nha: TobiasTheCommie: that's mostly right
TobiasTheCommie: nha: good good, because xbmc needs opengl2, and it works.. and if was wrong then it would be weird that it worked .)
TobiasTheCommie: :)
nha: onestone: you mean compiz works but fisheye is broken with that revision?
TobiasTheCommie: kraehe: the fglrx has improved quite a bit in the last year.. i think it is comparable to the nvidia driver by now.
nha: kraehe: I believe adding GLSL support to the driver (without support for branches and loops) wouldn't be that difficult, actually, but there's only so much an understaffed group of hobbyists can do ;)
onestone: nha: yes
kraehe: TobiasTheCommie, i guess the fglrx is as bad as windows ati drivers - and those are a no-buy for secondlife
TobiasTheCommie: ah, oki
kraehe: e.g. one typical ati question is: i can not see any avatar - answer: disable hardware skin accelleration
nha: ouch :(
kraehe: well - ati drivers work with sl - if one disables half of the accelleration for the so called 'windlight' - but then an 3860 is slower than an r200 (who just does not use the windlight features)
buggs: TobiasTheCommie, what is xmbc using opengl 2.0 for?
buggs: kraehe, no fglrx is worse than on windows
TobiasTheCommie: buggs: i don't know the details, but videoplayback is through opengl2, and the entire interface is opengl2 as well. all i can basically say is that "it uses textures"
buggs: which limits them to a few cards?
TobiasTheCommie: #in reality XBMC will today run with only OpenGL 1.4 + GLSL support"
TobiasTheCommie: "in reality XBMC will today run with only OpenGL 1.4 + GLSL support"
TobiasTheCommie: so, guess i remembered wrong
TobiasTheCommie: though there is a gsoc to do hardware video decoding through gl2
TobiasTheCommie: i'm not sure what that will require of the opengl
kraehe: what is the actual software version for the radeon driver - is there a gentoo overlay for it?
nha: onestone: I have the same problem with mesa 92c075eeb7c330ea420400d1c2bae57356b19f03 (all compiz gives me is a grey screen)
onestone: nha: so maybe something else is broken on your side
nha: looks like it
nha: ... which means I'll work on the other fp-related problems first
nha: after all, they might be related
nha: or it's a problem in the DDX
nha: hmm
nha: it really shouldn't be a configuration problem; after all, it worked just fine with the R420
TobiasTheCommie: kraehe: i'm using a git overlay on gentoo
nha: older versions of the DDX show the same failure :/
TobiasTheCommie: kraehe: http://dberkholz.wordpress.com/2008/03/30/hot-new-x-leetness/
osiris_: MostAwesomeDude: I reviewed your bicubic patch and found few bugs. So wake up, you've got a work to do ;)
onestone: MostAwesomeDude: I've found one big problem in the code
nha: oh for fuck's sake
nha: r500 TEXKILL appears to treat -0.0 as < 0.0
nha: time to look at specs
onestone: nha: can you tell me how to upload a FP32 texture right?
nha: onestone: in the driver? I think you can pretty much do what is done for RGBA textures - both are 32bits per pixel - just make sure that no swizzling or endian swap is done
onestone: nha: there is still something going wrong there
onestone: nha: its a ARGBFP32 texture = 128 bits per pixel
nha: oh
nha: I have to admit I'm not completely familiar with all the stuff that goes on with texture uploads
nha: do you have some code somewhere?
onestone: but is c float = radeon 32 float ?
nha: yes
nha: though there's the possibility of endianness swaps messing things up
syntropy: mornin
onestone: nha: http://dev.compiz-fusion.org/~onestone/bicubic.patch this is a modified version of MostAwesomeDude's bicubic filter work radeon_textured_video.c:292 uploads the texture and the formad is specified in radeon_textured_videofinc.c: 250 . I'm getting a nice gradient if I use a RGBA tex but the FP32 stuff is broken
nha: onestone: one thing that stands out immediately: why is txpitch the same for the two cases when in one case the bytes per pixel has to be multiplied by 4?
onestone: nha: 4 bytes * 4 components * 128 pixels
onestone: nha: the commented code is also broken
nha: so shouldn't the pitch be 2048?
nha: or is the comment just incorrect?
onestone: what code
onestone: we have several tex pitch values
onestone: nha: the comment is wrong the pitch for the card has to be in pixels
nha: ah you're right
ghepeu: hello
ghepeu: nha, I was trying to adapt your latest drm lockup fix to 2.6.26 drm. The first two pieces of the patch (r300_emit_draw_indx_2 and changes to r300_emit_indx_buf) apply, but the rest fails because in kernel drm there're no "dev_priv->track_flush" lines (they were introduced by glisse's r345xx hard lockup fixes).
ghepeu: Are they important or I can just ignore them and add the rest?
nha: ghepeu: I believe it's safe to ignore those lines
nha: in the sense that ignoring them can't hurt
ghepeu: I supposed so, because what you were doing was just adding a new call to a function for a type of packets and keeping unchanged the rest
nha: of course, my fix might be ineffective without the track_flush code from glisse (I don't think so, but who knows)
nha: exactly
ghepeu: but being drm...
ghepeu: I wanted to try that fixes because the description is very similar to my only reproducible lockup
ghepeu: I'll report back if it helps
nha: k :)
osiris_: onestone: try uploading only one component of FP32 and set rest to 0.0 with tx_format reg. 1- x component you can achieve using fp pre-subtract
onestone: osiris_: I need all 4 components for the real bicubic helper texture
osiris_: onestone: but that texture is used only in frag prog, right?
onestone: osiris_: yes
onestone: brb need to test something
nha: R500 should have reached correctness parity with R300 now as far as fragment programs are concerned
nha: unfortunately, I still don't understand why compiz is giving me a "grey screen of death"
osiris_: nha: good job
nha: :)
osiris_: onestone: you can upload only first component (bicubic_tex_128_float[i] = (float)i / 512.0;). components that are always 0 will be autogenerated by gpu with proper tx_format reg write, and 1 - first_component will be generated by fragment shader. that way texture pitch is 32bits (only during upload), and you can upload it like the video image texture (IIRC textures with pitch > 32bits have to be uploaded differently)
syntropy: blinks
agd5f: dmb: xaa is enabled and is the default.
onestone_: agd5f: airlied ping
agd5f: onestone_: pong
syntropy: pung?
jcristau: pang
onestone_: agd5f: I'm trying to fix the bicubic xv code. The texture upload is now working, but my problem is that if I enable TEX1 then it overwrites TEX0 somehow. fetches from text0 result in pixels from tex1 and fetches from tex1 are black
agd5f: onestone_: you have to specify which texture to sample from in the FP code and then assign an id to the texture in the texture setup
agd5f: that id is how the texture unit is linked to the FP
onestone_: agd5f: http://dev.compiz-fusion.org/~onestone/bicubic.patch so what is wrong?
osiris_: onestone: set id to 1 for R300_TX_FILTER0_1
osiris_: currently both textures get the same id 0, so TEX1 overwrites TEX0
agd5f: onestone_: what osiris_ said :) see R300TextureSetup() in radeon_exa_render.c for more
onestone_: got it
onestone_: testing
nha: * onestone_ testing
nha: <-- onestone_ has quit (Remote closed the connection)
nha: famous last words and all ;)
onestone: MostAwesomeDude: I have the texturing working (EXA with mask FP), but the bicubic FP is broken
MostAwesomeDude: Morning.
MostAwesomeDude: onestone: Hmm, excellent work.
MostAwesomeDude: I have to go to Corvallis and look at housing, but I have some time later to sit down and debug the FP.
MostAwesomeDude: Could you put up a patch with working textures?
onestone: yes. The output http://dev.compiz-fusion.org/~onestone/bicubic.png
onestone: MostAwesomeDude: http://dev.compiz-fusion.org/~onestone/bicubic.patch
MostAwesomeDude: Woot!
onestone: MostAwesomeDude: tex1 and it's coordinates are now correct
MostAwesomeDude: onestone: Very nice work.
agd5f: onestone, MostAwesomeDude: don't you want the exa w/ mask vertex program?
MostAwesomeDude: agd5f: Indeed we do, and that's already the selected one.
MostAwesomeDude: I'm just going over onestone's patch.
MostAwesomeDude: onestone: You have tex0 and tex2 references; shouldn't it be tex0 and tex1?
onestone: where?
agd5f: onestone: where you load the vertex program
onestone: agd5f: it uses the exa w/ mask program
MostAwesomeDude: onestone: No worries, I'm trying to pull out all the delicious bits.
agd5f: onestone: oh, you're right. the comment through me off
agd5f: *threw
onestone: MostAwesomeDude: I've changed texture setup, upload and delete and some values here and there. but the bicubic shader part is totaly broken
MostAwesomeDude: onestone: Yeah, definitely. The good news, though, is that everything DOES work.
MostAwesomeDude: 'cept the filtering shader.
MostAwesomeDude: And now that we know that...
spreeuw: hi thanks for implementing colorop
spreeuw: but it seems this application didnt make extensive use of it afterall, dont see real fps improvement
MostAwesomeDude: onestone: What's your preferred name and email for the git log? I'm not takin' credit for this particular patch. :3
MostAwesomeDude: Mm, BRB.
MostAwesomeDude: Hehe, yeah, the filtering FP is broken.
MostAwesomeDude: But, if you're sure that everything else works, then I'll go ahead and debug the stupid thing.
spreeuw: I tested the colorop acceleration, I think it works
onestone: I'm pretty sure
spreeuw: the app doesnt complain about fallbacks
spreeuw: and I didnt notice anything weird in the graphics
MostAwesomeDude: onestone: 'k. Could I have a name and email for the git log? I don't want to take credit for your work. ;3
nha: spreeuw: which application are you referring to?
onestone: MostAwesomeDude: Dennis Kasprzyk onestone@compiz-fusion.org
nha: spreeuw: very few apps use logicop; it's just one of those loose ends that I finally wanted to deal with
spreeuw: nha: Spring
spreeuw: a 3d rts game
MostAwesomeDude: nha: Nice work. Yet another low-impact fallback bites the dust.
MostAwesomeDude: Okay. Gonna go on the road trip, and then I'll fix the FP, and then we can have parties.
nha: the point size stuff is majorly weird
nha: it looks like point attenuation should be disabled, yet somehow the Z coordinate does have an effect on point size
nha: I'm not going to solve this today...
odz: :( looks like something in libdrm/mesa broke 2D accel in the last few days. Im noticing really sluggish proformance. /list in Konversation makes X use 100% cpu vs 40-50% before
spreeuw: no problem on type1 here ;p
odz: :(
odz: all i did was update mesa and libdrm
spreeuw: dont notice it in mozilla aither
spreeuw: anly upped mesa though
spreeuw: only
redeeman: well you could trty downgrade libdrm then
nha: odz: what redeeman said; in fact, it would be *really* useful if you could help pinpoint the exact cause
nha: for example, if downgrading the DRM fixes your problem, you can then use git bisect to search for the exact commit that causes the problem
nha: this will help us figure out what's wrong
odz: ok i'll try
nha: I am happy to announce that running Glest with shadow maps works now :)
rx__: :D
kurtr: Hello, I'm looking for help setting up a Xpress 200 card. Am I in the right place?
rx__: yes
kurtr: Yay.
kurtr: I'm getting the following:
kurtr: RADEON(0): No valid modes.
kurtr: I can post my config and logfiles if that is helpful.
jcristau: kurtr: posting them would be the first step, yes
kurtr: http://w140.com/xorg.conf
kurtr: http://w140.com/Xorg.0.log
kurtr: The box is a Dell Vostro 1000 laptop.
osiris_: onestone: hmm, I can't find any rasterizer instructions in your patch. how do you put texcoords on pixel stack?
onestone: osiris_: they are there somewhere. it's mostly the EXA w/ mask code
gentoofu: kurtr: https://help.ubuntu.com/community/RadeonDriver
kurtr: Thanks. Hopefully it isn't too Linux-specific. I'm running FreeBSD.
bridgman: kurtr; looks like the driver is not getting DDC information for any screens and doesn't think it is supposed to be dealing with a hardwired laptop panel; is this a laptop with no external display ?
bridgman: I'm not as familiar with the older GPUs but I'm not seeing the LCD panen in any of the connector information
bridgman: hello ?
bridgman: tap.. tap... is this thing on ?
kurtr: Yes.
bridgman: yes - laptop with no external display ?
kurtr: It has an analog VESA connector on the back.
bridgman: OK, (VGA ?) but nothing connected at the back ?
kurtr: Nope. Nothing is connected back there.
bridgman: OK. Does the display work OK with the vesa driver ?
bridgman: I guess maybe the first question should be "what happens when you start X ?"
kurtr: I was not able to get it to work with the vesa driver in my modern FreeBSD installation, but an old Linux live cd worked, using the vesa driver.
bridgman: I'm guessing the screen stays black ?
kurtr: Shall I switch the driver line to "vesa" and startx?
bridgman: assuming the vesa driver is installed, yes -- although I think you said you already tried vesa and were not able to make it work ?
kurtr: Right.
bridgman: I guess it might be useful to look at the x log for starting with vesa but this is sounding like a freebsd specific issue and I probably don't know enough to help
bridgman: but we can try :D
kurtr: I'll try it now just to read the error message...
bridgman: great. If you can paste the x log for vesa as well there might be a clue
kurtr: OK.
kurtr: http://w140.com/Xorg.0.log.vesa
bridgman: OK, will save that offline & look; need to hang up & make a quick call, back in 5
kurtr: Thanks.
kurtr: bridgman: I got the vesa driver working. Still no luck with ati.
airlied: kurtr: Vostro?
kurtr: It's a cheap Dell laptop.
airlied: kurtr: have you built from source
airlied: ?
kurtr: I didn't build Xorg from source. I built the driver from source.
airlied: good enough..
airlied: can you get lspci -v from the ATI chip?
airlied: I've had to quirk these chips before
kurtr: I'll post it in a second...
airlied: agd5f, bridgman: so there is a straps register in the rs480 NB_GC_STRAPS
airlied: and bit 28 of it is called MOBILE
airlied: now I'm wondering if that is means I can use it to figure out LVDS enabled or not
kurtr: http://w140.com/pciconf-lv.txt
kurtr: It is the output from the FreeBSD equivalent to lspci.
airlied: kurtr: ah I need the subvendor id.
kurtr: rtfming...
airlied: or is that card maybe.
airlied: kurtr: whhat version of -ati driver is that?
kurtr: Yeah, that's the "card" field. Checking driver version.
airlied: I fixed this for 6.9.0..
bridgman: airlied: dialling into office now
bridgman: agd5f may be the only one who knows where to find rs480 regspecs tho
airlied: bridgman: I've just seen rs4xx with LVDS and without LVDS and the BIOS doesn't tell us..
airlied: so I was hoping the straps might.
bridgman: understood; that was what puzzled me as well, no LVDS/panel message in the driver output, now I know why ;D
kurtr: I have version 6.7.195 of the ati driver. I'm compiling 6.9 now, which is the current version in FreeBSD's ports tree.
kurtr: Yaaaaaaayyyyyyyyyyyyyyyyy.
kurtr: I'm a loser for not updating my source tree.
kurtr: It's sweet now. Sweet.
airlied: kurtr: excellent..
kurtr: Thanks guys.
airlied: likes bugs he already fixed.
oga: that's everyone's favourite type
bridgman: I'm still dialling into the office, but will keep going in case I find anything about that strap ;)
airlied: bridgman: yeah I meant to ask about it before and forgot :)
agd5f: airlied: I'll take a look
bridgman: oh good, agd5f has high speed ;)
airlied: therre are some strap on r5xx also that might be "useful"
airlied: but I don't know anything about that :)
chithead: will the radeon kernel modesetting code also work on rv410 cards?
airlied: chithead: not yet.
airlied: this week or next week maybe.
bridgman: will check; but I don't trust the straps very much, I know where the settings come from ;)
chithead: from looking at the patch, it seems that most places only check for is_atom_bios
bridgman: yeah, it varies from one generation to the next; in general we're trying to use straps for things specific to the chip and BIOS for things that are specific to the system where the chip is used
bridgman: but in the earlier generations we couldn't do as much with BIOS
chithead: so what would happen if I run the atombios code on rv410? nothing?
bridgman: and of course everyone was flashing their damn bioses to enable pipes we had turned off for reliability
airlied: chithead: it might work.. it might not..
bridgman: nothing good
airlied: chithead: actually it won't
airlied: as I don't the setup for the scan out on the legacy chips written.
berniyh: bridgman: you said a few months ago, that you'll try to get docs out for the dynamic clockrate stuff (mainly for mobile chips), are there any news there?
lkro: airlied: did you just say: "this week or next week maybe"? Cool. Can't wait to try. ;)
lkro: airlied: did someone send you that pony after all? ;)
bridgman: berniyh: no news yet, getting 6xx out is taking longer than we expected
berniyh: k, thx
agd5f: airlied: I think for rs580 we need to parse the IGP table in the bios
agd5f: *rs480
agd5f: nevermind, that tabel doesn't seem to have any mobile vis desktop flags
agd5f: ah, I know. if the bios has a mobile info table, it's a mobility
airlied: agd5f: do we check for a mobile info table now?
agd5f: airlied: only when we look for lcd ddc information
odz: Xlib: extension "Generic Event Extension" missing on display ":0.0" <---anyone happen to know what might be cousing this warning?
odz: ugh
dmb: agd5f, i get that error message when trying to enable XAA saying to use EXA for blah or newer cards
agd5f: dmb: it says use exa for render accel
agd5f: xaa doesn't support render accel for r3xx and above, but it does support blits fills, lines, etc.
dmb: oh, my bad
TobiasTheCommie: agd5f: hehe, that sounds like something from spaceballs :)
TobiasTheCommie: Radar Technician: I've lost the bleeps, the sweeps, and the creeps
snogglethorpe: a while back I mentioned the radeon driver seemed to be doing nutty DPI calculations
snogglethorpe: here's a relevant snippet from Xorg.0.log:
snogglethorpe: (II) RADEON(0): Output None using initial mode 1152x864
snogglethorpe: after xf86InitialConfiguration
snogglethorpe: (**) RADEON(0): Display dimensions: (252, 179) mm
snogglethorpe: (WW) RADEON(0): Probed monitor is 280x210 mm, using Displaysize 252x179 mm
snogglethorpe: (**) RADEON(0): DPI set to (169, 227)
snogglethorpe: ... according to my calculations, that DPI values is ... not correct
snogglethorpe: the correct dpi should be about 116x122 i guess
airlied: snogglethorpe: its a server bug then..
snogglethorpe: the dpi value actually reported by xpyinfo, on the other hand, is 96 x 96 ... (and I have no idea where _that_ is coming from)
airlied: I think its all worked out in the generic code.
snogglethorpe: airlied: so even though the msgs are marked "RADEON", it's actually generic code?
airlied: snogglethorpe: yes code in hw/xfree86/modes in the X server.
snogglethorpe: ok
snogglethorpe: thanks
airlied: though quite where that Probed monitor line is coming from I'm not sure.
snogglethorpe: airlied: well anyway, at least _that_ info seems to be correct :-)
chithead: snogglethorpe: on my notebook the display had a wrongly programmed edid, maybe you can check the edid from the log where the 252x179 comes from
snogglethorpe: chithead: 252x179 is correct, it's actually what I specify manually in xorg.conf
bridgman: ahh, I was wondering why there were two sets of dimensions
chithead: or the 280x210 mm
chithead: bridgman: actually, the edid contains two dimension fields, one for the monitor size and another for the size of the display at preferred resolution
airlied: snogglethorpe: have you set a virtual line?
snogglethorpe: airlied: hmm not sure what that is, but I don't think I did
airlied: it works out the dpi from the virtual screen size.
airlied: which is probably 2560x1600 or something
GerbilSoft: trying to figure out this cropping problem in VLC
GerbilSoft: if i select 4:3 cropping with Xv, the image gets pushed over to the right and the right part of the image isn't visible
GerbilSoft: but it works in X11 mode
snogglethorpe: airlied: how can I check if that's set (I didn't specify anything like that in xorg.conf, but ...)
airlied: snogglethorpe: the default is 2560x1600 so you'll get that most likely.
snogglethorpe: airlied: hmm so it's a bug if it uses the virtual size for dpi calcs, right?
airlied: snogglethorpe: kinda.. dpi is just one major clusterf**l
airlied: snogglethorpe: kinda.. dpi is just one major clusterf**k even.
snogglethorpe: airlied: one problem is that while I'm using the debian "experimental" server, it's still not the bleeding edge, so it's very possible these thigns have been fixed
airlied: snogglethorpe: well the problem is DPI is really per monitor, but X tries to do it for the desktop.
airlied: or for the screen.
snogglethorpe: ugh
airlied: it doesn't understand the screen is not the viewport.
airlied: randr 1.2 should fix that properly.
airlied: so you get dpi per viweport, however what happens with two monitors with differetn dpis is very undefined.
snogglethorpe: hm
snogglethorpe: the main place it seem to have an effect is font size
snogglethorpe: airlied: is the "1.2" version number above visible in the binary anywhere?
snogglethorpe: airlied: the debian package version for "libxrandr2" is 1.2.3, but I suppose that might be something else entirely
airlied: snogglethorpe: if you run xrandr you should see dimensions.
snogglethorpe: hmm
snogglethorpe: says "current 1152 x 864, maximum 1680 x 1600"
airlied: so you are getting dpi from a 1680x1600 screen most likely.
snogglethorpe: airlied: yeah, if I do the dpi calculations using that, it's exactly the numbers from Xorg.0.log I pasted above
snogglethorpe: (169 x 227)