kcodyjr: hey RTFM_FTW, learned something. when we say a 'linear' framebuffer, we're in fact still talking about sRGB. merely de-gamma-compressed.
krig: hey
krig: I'm getting this when using my compiled drm.ko from r6xx support branch: http://paste.ubuntu.com/118383/
krig: anyone have an idea of what might be the problem?
da1l6: krig: have you updated both, drm and radeon module
da1l6: ?
krig: da1l6: hm yes that seems to be it, radeon.ko is old.
krig: da1l6: thanks
krig: da1l6: fixing radeon.ko did the trick, it's now working beautifully :)
Toksyuryel: hurray for working beautifully :)
udovdh: hello
udovdh: just had a lockup on my dual-screen system
udovdh: while trying to test out latest git of drm and radeonhd r6xx support branches
udovdh: I pulled radeonhd and drm from git to have the latest
udovdh: after I had updated to 2.6.28.5
udovdh: on my phenom based box with hd2600pro and 2 lcd monitors
udovdh: I built r6xx branches for radeonhd and drm
udovdh: and copied driver and drm/radeon modules to the right locations
udovdh: (after a reboot drm is even autoloaded!)
udovdh: then I did an init 3
udovdh: edited xorg.conf
udovdh: and did init 5
udovdh: then the pc hang
udovdh: now it boots up fine
udovdh: and Xorg shows normal stuff
udovdh: only `exaCopyDirty: Pending damage region empty!` at the end
udovdh: have to check the screens
udovdh: (pc is upstairs) in X
udovdh: why would it hang?
udovdh: and boot up and start X fine afterwards?
udovdh: only other thing that was going on at that time was an nfs copy of a few GB's of data
udovdh: right now that nfs copy going very slow
udovdh: (few MB's/s over GBit...)
_GNR_: radeonhd git r6xx-7xx branch is pretty unstable to me, I keep using 1.2.4
udovdh: also: is this normal?
udovdh: see http://pastebin.com/d22573d75
udovdh: I see why nfs is slow now: raid is rebuilding
yangman: udovdh: VT switching back to X will cause xserver to hang. known issue
udovdh: also?
yangman: udovdh: mtrr warnings are normal, depending on how you have fb setup
udovdh: hmmm.
yangman: it's harmless, afaik
udovdh: I did not set up anything specifically in that area
udovdh: box is as it is
udovdh: aside from some bios settings
udovdh: and a custom kernel
udovdh: F10 for the rest
udovdh: the VT thing is bad
udovdh: because that is what I did when I found out the box was unresponsive
udovdh: it's also not so useful when testing out the new driver
udovdh: wgat about the writeback failed message in http://pastebin.com/d22573d75 ?
udovdh: what...
udovdh: related to the mtrr messages?
udovdh: to be ignored?
cristiklein: hi everybody
cristiklein: I wanted to ask whether we are supposed to give feedback related to r6xx-r7xx-support
cristiklein: or wait until more work is done and wait until it gets stable?
nanonyme: cristiklein: Well, what's the point of giving out experimental source code to users if they aren't going to tell how it works? ;)
cristiklein: nanonyme: I though it was just to calm the unpatient :)
cristiklein: in that case
cristiklein: i have the following problem
cristiklein: r6xx-r7xx hangs without the radeon drm driver loaded
cristiklein: the system is frozen solid
cristiklein: how could I gather enough debugging information, to find something useful?
nanonyme: Out of interest, why aren't you loading the radeon drm?
cristiklein: i like to switch between the ati and radeonhd drivers
nanonyme: You can't do that on the fly.
cristiklein: as the radeonhd one is not as good with rotating
nanonyme: Also radeonhd will not run with fglrx kernel module loaded.
cristiklein: the thing is, other xorg drivers are able to load the drm module automatically
Toksyuryel: I believe I have located my problem from before.
nanonyme: You need to prevent fglrx kernel module from loading, boot, then load radeon drm modules, then start radeonhd.
Toksyuryel: It wasn't an issue with fglrx doing something to mesa; rather, I require a 32-bit version of mesa that is the same as my 64-bit version
Toksyuryel: it turns out that the package that has the 32-bit versions of things only pulls in stable packages
Toksyuryel: so it had an old version of mesa
nanonyme: Toksyuryel: There is no 3D support yet for r6xx-r7xx in radeonhd anyway.
Toksyuryel: I found a package with the 7.2 version that I am installing now
Toksyuryel: nanonyme: there is in r5xx though
nanonyme: Of course.
Toksyuryel: I have r5xx :)
nanonyme: That's completely irrelated.
nanonyme: Toksyuryel: Damn, I take a break. :)
Toksyuryel: hehe
Toksyuryel: uses an X1550
nanonyme: So it was cristiklein with r6xx-r7xx and you with r5xx.
cristiklein: :)
nanonyme: cristiklein: Anyway, my point was, you can't simply change on the fly between fglrx and opensource drivers with drm.
Toksyuryel: I'ma be ecstatic if I can play EVE with this thing
nanonyme: It was somewhat possible without any drm but can cause unexpected effects now.
nanonyme: (Since fglrx leaves the registries in a different state than they are just after boot)
Honk: changing from oos drivers to fglrx works just fine though *g*
nanonyme: :P
Toksyuryel: lmao
Toksyuryel: no... no it doesn't D:
Honk: pff =)
Honk: 't works for me, that's all that counts ;)
nanonyme: Honk: Maybe they know how to reset the registries without booting? ;)
nanonyme: Some undocumented feature.
Toksyuryel: that is probable. they are primary windows coders after all
nanonyme: Well, ATi did make the cards, they probably know quite well what it does in each scenario...
nanonyme: (Or the chipsets anyway)
nanonyme: Even if it's not a planned feature but a found feature.
Toksyuryel: on package 28 of 38
Toksyuryel: I may have to recompile wine though, I dunno if it will make use of the 32-bit libraries as-is
Toksyuryel: IT WORKS
Toksyuryel: IT WORKS
Toksyuryel: I can play EVE with radeonhd :D
chemart: how do i set position and size of image displayed on my lcd display?
da1l6: what kind of connection is used (VGA, DVI, etc)?
da1l6: In general: output modes (Resolution, Frequency, etc) are configured using the "xrandr" command or frontends for it.
da1l6: For VGA connected lcd's use the Auto Adjust button on the moitor to make the image fit the screen. For other (digital) connection this should not be needed.
Toksyuryel: I spoke too soon, still having problems getting EVE to work. However I do not believe they are related to radeonhd. I think ALSA may be to blame.
udovdh: Toksyuryel, what is EVE?
Toksyuryel: udovdh: imagine if Elite was an MMORPG
Toksyuryel: udovdh: that's basically EVE
udovdh: aha, ok, thanks for the info
Enverex: Or Frontier Elite II...
udovdh: just checked the r6xx branch with DRI on my dual screen setup
udovdh: and it looks better than 1.5 or 2 weeks ago
udovdh: windows are quick
udovdh: and I did not yet see corruption
udovdh: so maybe time to switch to r6xx for this 24/7 workstation?
udovdh: (it should just work, that is...)
Veza: Is the firefox paint&drag fixed already?
udovdh: or are any issues remaining for rv630?
udovdh: didn't check that
udovdh: Veza, how does that issue look?
Veza: there comes strange box to top left corner, with copy of ff page
udovdh: Veza, had a look but I couldn't reproduce that one yet...
yangman: sounds like the overlapping copy problem. that was fixed
yangman: the only major known bug right now is X hanging on VT switch back
udovdh: if that's fixed it looks 100% usable for me
Toksyuryel: I have a question
Toksyuryel: is the distinction between whether or not a card supports OpenGL 2.0 or 2.1 strictly a hardware question? or is it possible to code 2.1 support into a driver for a 2.0 card?
Toksyuryel: in other news, I manage to save the output from wine for this most recent EVE crash
Toksyuryel: anything in here relevant to this driver? http://dpaste.com/120922/
nha: hmm, I'm not sure about the difference between glsl 1.20 and 1.10
nha: apart from that, there's sRGB textures
nha: which it might be possible to emulate, awkwardly, using a shader, in case the hardware doesn't support them natively
RTFM_FTW: doing sRGB via the programmable path isn't too difficult actually
RTFM_FTW: outside of that (concerning 2.0 -> 2.1) you have PBO moving into core as well
nha: RTFM_FTW: only post-filtering, though
nha: and PBO doesn't really require dedicated hardware
RTFM_FTW: well nothing mentioned above really requires dedicated HW
RTFM_FTW: it just makes the job easier / faster :P
scaroo_: Hi there, i just experienced (for the second time) a hangup while scrolling in the xchat chan window. I am using latest r600/r700 branches of both drm and radeonhd. Also nte that the xserver do not seems to be fully hanged as the mouse cursor is still moving, I just dont have any input on the displayed windows
scaroo_: where should i look for the latest log before the crash so i can provide more meaningful data ?
yangman: scaroo_: is it reproducable reliably?
scaroo_: well it happened me three times already, and well, this is my main and only machine, i d prefer nt reproduce it as i cannot ssh into it to kill the X server... have to hard reboot.
scaroo_: Step to reproduce : scroll in the xchat-gnome "chat" window up and backward
scaroo_: result : display not corrupt, pointer still responsive, but no event seems to be pass to the clients
scaroo_: being mouse and kb events
yangman: ok. what hardware?
yangman: I'll try and see if I can reproduce it when I have time
scaroo_: RADEONHD(0): Detected an M76 on an unidentified card
scaroo_: te machine being an intel 24" imac
scaroo_: m76 = 2600XT Pro, i think
scaroo_: or rv630 it seems
scaroo_: yangman: i have the followingline at the end of my xorg log : exaCopyDirty: Pending damage region empty!
bridgman: airlied; pong-ish
osiris_: great, cross channel ping :)
bridgman: oops, never mind ;)
Zajec: scaroo: i expect that in some situations... r6xx-r7xx is not 100% stable yet
scaroo: Zajec: for sure, thus a report here :)
kcodyjr: well, bridgman, MostAwesomeDude, i have good news and i have not so good news. the good is, there does indeed exist a matrix that can translate any tristimulus space into any other tristimulus space, including those with imaginary primaries
kcodyjr: the bad news is, calculating the matrix constants requires a lot of knowledge about colorimetry. it can be done but there are a number of challenges.
kcodyjr: challenge one; these data are ultimately based on various experimental measurements of the eye's responses, resulting in tables, but which need to be thought of as functions. i saw something about a "cubic spline method"?
kcodyjr: challenge two; it is not clear whether linear or logarithmic views of the chromaticity space will be more accurate. this will simply require trying it both ways.
kcodyjr: challenge three; even brand new monitors, even those still on the drawing board, carry their chromaticity information in the old 1931 format. these data will need to be converted and the method depends on the anser to challenge two
kcodyjr: and finally challenge four; even simply pulling the luminance out depends on the luminous efficiency functions which are defined by wavelength. the real display primaries are not monochromatic, so i will have to make and then verify assumptions about choosing an 'equivalent' pure wavelength for the purpose of calculating the primary's luminosity contribution
bridgman: maybe we'll get lucky and when you round off to three decimal places most of that stuff won't matter :)
bridgman: crosses fingers
kcodyjr: hopefully. but i can tell you right now there's a problem at the 1st decimal place if i don't figure out how to properly interpolate those tables into functions.
kcodyjr: i mean it's not like they could really ask their test subjects to do comparisons for every .001nm; usually it's given in 5nm steps and i'm pretty sure that's interpolated too
bridgman: there's a great thread on avs (I think) from a guy trying to figure out why he's seeing three different conversion matrices for going from (IIRC) CIE XYZ to sRGB
bridgman: he laboriously types in all the matrices
bridgman: first guy says "well, I rounded xxx off"
bridgman: second guy says "I rounded yyy off"
bridgman: third guy helpfully points out that this cmopletely explains all the differences
kcodyjr: there are established CIE standards for precision in those constants (but only for those well defined spaces)
kcodyjr: this, incidentally, seems to be the most recent word on what 'modern standard' means http://www.iscc.org/aic2001/abstracts/symposium/How_CIE/Vienot-S.rtf
kcodyjr: and they are a far cry different from XYZ and its cousin xyY
kcodyjr: even LUV i'm finding i have to let go of, because it's based on scaling and rotation factors applied to XYZ
kcodyjr: all that's getting tossed because the color matching functions were inferred from colorimetry data, until the 1959 dataset started measuring more directly
kcodyjr: in terms of implementation, this means that i have to take the raw experimental data and apply the prescribed algebra to produce the various derivatives; otherwise live with having function tables taken from inconsistent data sources (!!)
bridgman: not sure I would let this paper change your mind; it seems to be based on an awful lot of assumptions and hypothesis
bridgman: more than it seems to prove at the end
bridgman: I'm not sure "physiologically relevent" is better than perceptually relevent
kcodyjr: the difference is simply in which direction the analysis is done
kcodyjr: and therefore where within the food chain the highest accuracy is to be found
kcodyjr: and that paper is simply the statement from the CIE, there's no meat to it
bridgman: yeah, I noticed it ended rather suddenly ;)
kcodyjr: but they being the standards body, i'm inclined to think that the MacLeod-Boynton (r,g,b) space (not to be confused with CIE RGB) will eventually supersede XYZ
bridgman: I'm liking sRGB more every day ;)
kcodyjr: sRGB is actually a horribly limited gamut
kcodyjr: and its successor, scRGB, is downright vile
kcodyjr: all of these widely used standards are defined in terms of the old 1931 CIE xyY space; that is, whatever your 3 primaries are, they're defined by the (x,y)
kcodyjr: that old (x,y) plane was specifically designed to put the entire gamut within the triangle (1,0), (0,0), (0,1)
kcodyjr: scRGB (pushed by Microsoft and used in Vista, of course) gets around the "triangular gamut problem" simply by defining 3 primaries way outside the horseshoe, 3 of which are negative
kcodyjr: sorry 2 of them are negative, one in both axes, and the 3rd is still way outside that triangle. makes everything's assumptions about bit precision invalid.
kcodyjr: so the steps i've outlined myself; 1, encapsulate the raw tables as interpolated functions somehow; 2, reuse that to (summary) derive the horseshoe diagram; 3, translate -that- into a polar coordinate space centered on a chosen whitepoint for use in translating real primaries into their ideal monochromatic equivalent; 4, now that i can generate luminosity coefficients, implement the code to translate tristimulus into luminance+(r,g
kcodyjr: ,b) coordinates; 5, implement the code to triangulate the chroma from the 3 new primaries' coordinates and recombine with luminance
kcodyjr: somehow all that crap has to get boiled down to a matrix but better i make sure it works in a more debuggable way first
kcodyjr: relatedly; while it should surprise noone that ambient light and the calibrator's eyes' chromatic error, i've also found that viewing distance plays a strong role in perceptual equivalence
masa-: hmm, can't i create a new branch if i have unsaved changes on my working tree?
masa-: without overwriting those files
MostAwesomeDude: masa-: "git stash"
masa-: oh..
masa-: thanks
MostAwesomeDude: Sure.
kcodyjr: ooh. thank you, GNU scientific library. wait. i think. it's GPL. is that, then, prohibited in an X driver?
MostAwesomeDude: kcodyjr: No, but it would prohibit it from being hosted on fd.o IIRC.
MostAwesomeDude: synaptics had that issue for a long time.
kcodyjr: oy.
kcodyjr: have to find another math library, then. do all dependencies have to be BSD/MIT? or is LGPL allowed?
MostAwesomeDude: You could just not use a math library.
MostAwesomeDude: libc should have everything you need.
kcodyjr: for cubic spline interpolation? doubt it.
kcodyjr: but i'd love to find out i'm wrong on that one.
kcodyjr: ... found one that's LGPL (called SPLINE) but the bastard is in C++, which i'm prejudiced against. would that be a dealkiller anyway?
kcodyjr: hmm. nope. LGPL is licensa non grata as well
kcodyjr: ok. MostAwesomeDude, i want to avoid GPL, but there just ain't anything else that's ready to rock. would GPL still screw me if i used it for now and replaced it later?
kcodyjr: or alternately, here's an idea: what if i built the color correction system as a standalone library whose job was simply to provide the 3x3 matrix constants? an optional driver dependency. if absent the driver can just skip the correction (where applicable) or use a fixed set of constants (where necessary). would GPL be allowed in such a usage?