gris: I am trying to figure out how colormaps and such work with the framebuffer subsystem. when running in 32 bit mode, how does the radeon card address colors? the visual says it is directcolor, but that doesn't mean much to me atm
airlied: gris: there is a lookup palette
airlied: that is 1:1 usually
ganastasiou: hello
kcodyjr: airlied, (reading back), so then it's possible to achieve color correction by carefully programming the LUT's?
jarda-wien: hello, I am having a problem runing a dualscreen setup on my T41 (radeon 7500) laptop, everything works fine except when one monitor is used in pivot mode (extremely low lerformance)
kcodyjr: pivot mode? you mean rotated?
kcodyjr: it could be that RandR isn't getting rotation acceleration, but it surprises me that something as old as an r100 would have any trouble at all with that
jarda-wien: yes, everything set using xrandr
kcodyjr: and if you set it non-rotated, it speeds right back up again?
adamk: jarda-wien: xrandr uses the 3D engine to accelerate rotation. Unfortunately, your card has a maximum 3D texture resolution of 2047, which you are likely exceeding.
jarda-wien: it does... with dri
adamk: 2048, rather.
kcodyjr: i think adamk may have just hit it, since r100 is expected to have rotation accel
jarda-wien: well my virtual desktop size is set to 2304x1280
adamk: Hence the problem...
adamk: Unfortunately, I'm not sure there is a solution.
jarda-wien: what about a lower color depth?
kcodyjr: doesn't change the resolution limit
adamk: No. It has nothing do to with video ram, but it is a hardware limit with the GPU.
jarda-wien: too bad...
kcodyjr: uses an 11 bit value for the coordinate, by the looks of it
jarda-wien: would there be a way orund this? second x server?
kcodyjr: yeah, don't run them as a unified desktop, but rather as two separate ones
kcodyjr: which means you won't be able to drag windows between them
adamk: Except that will disable Direct Rendering in the X server.
adamk: Which means no 3D engine and then you get software rotation again.
kcodyjr: adamk, i thought direct rendering was simply restricted to the 1st head?
adamk: kcodyjr: Not last time I tried. Even having multiple screens disabled DRI.
adamk: It has been a while, but I have not heard of any changes in that missing functionality.
kcodyjr: well, that's new... and it does leave you SOL, jarda-wien
kcodyjr: newer chips have a higher limit, right?
adamk: r500 and above are at 4096.
adamk: Hmmm.
kcodyjr: then jarda-wien, your only solution if you must run such a configuration, is to do it with a newer laptop which has an r500 or better
adamk: jarda-wien: The screen you want to rotate... Is it the one that passes the 2048 limit?
jarda-wien: looks like i am out of luck today...
kcodyjr: ooh, that's interesting adamk
jarda-wien: i have a secondary 1280x1024 lcd and the 1024x768 laptop sceen
kcodyjr: wait, stack them top-bottom rather than left-right
adamk: Because I'm thninking it *might* work if the rotated screen were completely within the 2048 limit.
adamk: Or you can stack them vertically, as kcodyjr suggests.
jarda-wien: nice one indeed, why haven't I thought of this earlier...
kcodyjr: would have been cool though, comment out the resolution limit test and see how well it behaves in the first 2048 ;)
jarda-wien: give me a few secs, trying right now
kcodyjr: but i believe that would have been a 'yes', the one that rotates passes the 2k limit... assuming it's picking up the internal screen as primary
jarda-wien: ok i just set the virtual desktop size to 2048x2048 and it didn't work either
jarda-wien: even rotating only the built-in screen is slow as hell
kcodyjr: hrm. try setting the virtual to 1280x1792
kcodyjr: no wait
kcodyjr: you'd actually want 1024x2048
kcodyjr: that may piss it off right there... adamk, is it testing for < 2048 or <= 2048?
adamk: Not sure... But i would assume that 2048 is safe.
jarda-wien: tried 1024x1024 and rotating only the built-in screen, again slow, even moving windows around in openbox
kcodyjr: ok, that means something else is wrong
adamk: Very odd...
adamk: Maybe I'm completely wrong about r100 rotation.
kcodyjr: it sounds like it isn't supported at all
kcodyjr: or at least, it's failing to activate
kcodyjr: snappy on both screens when you're not doing any rotation?
jarda-wien: last thing i tried was rotating only the built-in with the external completely disabled
adamk: I think one of the dev's may need to comment on whether it's supported.
adamk_: Unfortunately, my one machine with an r100 GPU is at work.
kcodyjr: heh wtf, you're in here twice?
adamk_: I'm bouncing between multiple machines.
kcodyjr: i've only got an r300 and an rv610 at my disposal
kcodyjr: ooh, actually it's an rv350, and still no help ;)
jarda-wien: weird, using both monitors and rotating the built-in throws some garbage to the normal oriented secondary
jarda-wien: the rotated one still slow...
jarda-wien: i could provide some more info, nut sure where to start thou
kcodyjr: i wouldn't know where to start, not being able to replicate the setup
jarda-wien: i have to go to eat right now, but will leave the chat open and come back later, in case someone here has a r100
kcodyjr: hmm, i'd forgotten how the old ones did that... that rv350 actually shows up as two devices on the bus
Phlogi: is this guide still up to date? http://tirdc.livejournal.com/23805.html
Phlogi: is modesetting-gem in mesa/drm master?
kcodyjr: far as i know, modesetting-gem is in modesetting-gem
Phlogi: kcodyjr: ?
kcodyjr: you're asking about git branches? i have not seen evidence of modesetting on the master.
Phlogi: is there any document that describes how to get gem with radeon and latest xorg?
Phlogi: kcodyjr: so its not in master
kcodyjr: you just pasted the only such doc that i'm aware of
kcodyjr: though it looks different, there may be other copies, but the repository info looks the same
kcodyjr: hrm though, one of those comments talks about merging modesetting. hmm. i guess i don't know.
Phlogi: kcodyjr: ok... would be a bit easier if there exists a guide for gentoo :)
kcodyjr: this stuff is soooooo experimental that distribution packages would be meaningless
chithead: Phlogi: for gentoo it is easy, you can simply modify the live git drm, libdrm, mesa, and xf86-video-ati ebuilds to pull from the desired repositories/branches
kcodyjr: which is not to say that installing packages built from git sources to a running system is necessarily a good idea.
kcodyjr: in fact you might be just as well advised to play in traffic
chithead: if it doesn't work you can simply return to the releases, after all the git ebuilds are handled by the package manager
Phlogi: chithead: jup I know..
kcodyjr: true. just making sure you knew to keep your head down ;)
Phlogi: chithead: I found some nice forum thread now...
Phlogi: I'm just not sure yet if I should waste some time with that :)
chithead: there is little advantage in kms for radeon, other than driving you monitor at its native resolution in console, atm
kcodyjr: that's a pretty strong advantage for some though
Phlogi: hmm yes... I think I'll wait some time, thanks anyway
Phlogi: I thought that maybe some issues will go away that I have with radeon
chithead: if you work most of the time in X, it is probably not worth the hassle and disadvantages
PuffTheMagic: airlied: ping
jarda-wien: i am back
jarda-wien: adamk: you said you had a r100 at work
adamk: jarda-wien: Yes.
jarda-wien: could you try it at work? i can come tomorow...
adamk: I won't be back in the office for a few days.
jarda-wien: looks like I really have bad luck today LOL
jarda-wien: doesn't matter, i will leave it for a few days, and then, I'll see
adamk: You may want to try back here tomorrow when, hopefully, some of the developers are around.
jarda-wien: I will, thanks for trying to help!
kcodyjr: yeah, they're taking an uncharacteristic break from the phosphors ;)
kcodyjr: and MostAwesomeDude may have actually gone to get some sleep... ;)
kcodyjr: welcome back Urigeller23
Urigeller23: is that a script or just kindness (;
kcodyjr: kindness, i left scripts behind about the time BitchX stopped being cool
Urigeller23: I thought so, but the prompt reaction made me wonder, sry (;
kcodyjr: coincidence, i happened to be paying attention
kcodyjr: and the reason for that is, i keep looking for someone that can help me figure out a deeply buried server startup behavior, but i fear i may be walking where angels fear to tread
kcodyjr: or at least, anyone except the original MIT students...
Urigeller23: good luck with that.. aren't there some X developers who work with this "core" stuff?
kcodyjr: if they're around they ain't answering
kcodyjr: but i'm not going to get anywhere so long as the frigging server unloads my module right after a successful init. doh.
Urigeller23: hm, strange
kcodyjr: obviously i'm failing to set something which indicates the module is in use
kcodyjr: what that might be, i'm losing patience trying to figure out
kcodyjr: there is another wrinkle though: my driver module links to an external library which itself dlopen's modules
Urigeller23: maybe look at other modules?
kcodyjr: that's what i've been doing, radeonhd and avivo in particular
kcodyjr: on the whole the avivo driver is a nice clean example of how to plug in to X, although the actual control-the-chip parts are abandoned
Urigeller23: of course
Urigeller23: hm
kcodyjr: it's going a good way into initialization too, i'm at a loss why it would think the module is unused after getting through PreInit
kcodyjr: but i slipped in a few submodule loads, and indeed it unloads them
kcodyjr: this is what i'm getting http://pastebin.ca/1324492
Urigeller23: not very informative ^^ at least not to me, seems okay except for the end
kcodyjr: yeah, it is ok right up until it unloads those modules
kcodyjr: what's -reallly- pissing me off, is that it then calls ScreenInit anyway, in a supposedly unloaded module!
Urigeller23: yeah that sounds odd..
kcodyjr: and even then, the blasted segfault comes during a subsequent module load, not while calling a function that should no longer be there
kcodyjr: i have determined that it is my underlying library that's causing the segfaults; module loads before my library inits succeed, afterwards they fail
kcodyjr: that's likely got something to do with the fact that the library, itself, dlopen's its own driver modules
Urigeller23: maybe X doesn't like that ^^
kcodyjr: that's what i'm thinking, but then i'd have to wonder just how X is f'ing up a glibc call
jarda-wien: hey I am back with some news... I tried using the EXA acceleration method insted of XAA and the rotated screen is usable now! but dri seems to be disabled (low glxgears performance)
jcristau: glxgearsisnotabenchmark
jarda-wien: i know, but normally i get around 700fps and with EXA around 90, I know there is a way to know if dri is enabled, but I can't seem to rember it
chithead: glxinfo
kcodyjr: jcristau, is that a script? ;)
jarda-wien: how could I forget about that... stupid
kcodyjr: though it is a fair question: are glxgears numbers even the least bit informative when taken as an order of magnitude?
kcodyjr: ie, can 90 be fairly said to suck compared to 700?
kcodyjr: or is even a 10:1 difference just not meaningful
kcodyjr: hmm. think i may have found what i'm doing wrong. looks like the unloader is keying on whether the driver has any entities, which it does, but i'm not reserving the resources
kcodyjr: (thank god for grep)
jarda-wien: ok so having a virtual desktop size of 2304x1280 disables dri, BUT only with EXA, so i get dri with exa and lower virtual size
jarda-wien: using a lower color depth is ok with dri, even with 2304x1280
jarda-wien: strangely, using the rotated secondary screen@1280x1024 is slow, switching to 1024x768 is perfect!
jarda-wien: so it looks like there is a 2048 texture limit, but it is not applied to the virtual desktop size,but to the physical size
jarda-wien: at the end I have been able to configure everything as ecpected, only two issues remain: firstly I can only use the rotated VGA-0 output at 1024x768 (it is slow at higher resolutions)->no problem at higher resolution with rotation off
jarda-wien: secondly I have to use 16bit color depth
jarda-wien: using 24bit works fine, even with dri and the large desktop, but trying to rotate the secondary sceen produces: xrandr Configure crtc 1 failed
kcodyjr: hmph. found my unloading issue. my own stupidity at work.
jarda-wien: adamk: I will try to reach you tomorow and not to forget anything I found out today
agd5f: rotation is only accelerated with EXA
lymeca: Hi, I run Debian Lenny
lymeca: I'm trying to install 0.6.10 onto it from experimental
lymeca: but when X11 loads it apparently cannot find the radeon module
gustaf2: i'm getting _rather_ annoyed. some month ago I complained that one of my monitors in a dual-head setup has started to "flicker" (turn off/on, as if it changed mode). this usually happened when I had the thunderbird window on that monitor. I changed _a lot_ of git revisions to bisect but with no success. no, I run evolution (for work mail), and the same thing happens! it's so completely fucked up, but for some reason, thu
gustaf2: if anyone has a clue, please help, this is really making me mad.
gustaf2: no->now
chithead: gustaf2: you ruled out a hardware issue? does the same thing happen if you boot from livecd?
chithead: if you swap the connectors on the graphics card, does the problem persist?
gustaf2: it can be ok for a long time, and then start to happen frequently.. sure, livecd could be an idea, but what livecd works with _proper_ dual head detection?
chithead: if it is not detected properly, set it up via xrandr
gustaf2: chithead: I did quickly swap before christmas, but perhaps too short. i'll swap again, and leave it like that for longer...
gustaf2: chithead: heh, of course. didn't think about that.
gustaf2: is there some way to detect why a monitor gets its mode changed?
chithead: no, but you might get messages in /var/log/Xorg.0.log if the driver is responsible for that
gustaf2: yeahm I have some "Output DFP3 enable success" and "unblank succes" etc, but far too few..
gustaf2: just as before.. when I swap connectors - nothing..
gustaf2: as if it is some spookey "that particular monitor" on "that particular output" causes it... wtf!
chithead: I had this problem on my old 9600xt and its dvi output. every time starting a 3d app, the picture would randomly become dark for a few seconds. I decided to stress test it, and some smd part on it blew up after a few hours
gustaf2: heh.. so you mean it's the gfx card?
gustaf2: that's good, because my new not-even-a-year-old expensive IPS-panel monitors is something I don't want trouble with..
chithead: yes, I still have it. the smd part is scarred beyond recognition, maybe I will try to find out what was there and try to replace it
chithead: one day
gustaf2: what's smd?
chithead: surface mounted device
chithead: could be a resistor
gustaf2: ah
gustaf2: well heh.. my computer is water cooled, and the gfx chip too, and the whole setup has caused the gfx card to have become rather seriously bent down by water cables pulling it.
gustaf2: the "free" corner, so to speak, is like 1-1.5 cm bent down ;)
gustaf2: perhaps that's adding to it, if not being the issue itself
gustaf2: btw, thank god fod xrandr, I just got the idea to swap the monitors with --left-of, after having swapped the connectors...
chithead: if you bend a card too much, the circuits may become damaged
gustaf2: yeah... but I need the water cooling...
gustaf2: not for performance, not at all, i don't overclock or nothing... but for the noise.
chithead: you could rotate your case by 90 degrees. (may require to replace the cd/dvd drive with a slot-in model)
gustaf2: hah! now it flickered... the other monitor. so it's the gfx card all right.
gustaf2: chithead: not a bad idea... with the pump and everything, I'll have to see how that could be done, but a burnt gfx card is perhaps not that fun.
chithead: gustaf2: you could try to find settings that do not trigger the flicker, eg. 16bpp color
gustaf2: btw do they burn as in burn? or just die? cause I don't wnat fire in that machine (important data) ;)
chithead: well the resistor or whatever it was made a "pop" sound
gustaf2: haha
gustaf2: i mean, i'm sorry ;)
chithead: I got a cheap x1600 and moved on
gustaf2: lol, I have a cheap X1600 =))
gustaf2: but I could probably just add a support... i gotta be an idiot.. why haven't I thought of that? a little wood stick to add support for that free corner of the gfx card..
TobiasTheCommie: gustaf2: tie a piece of string around the water cable and tie it to the top of the machine to pull it away from the gfx card.. isn't that a better option?
TobiasTheCommie: afk
gustaf2: TobiasTheCommie: could work, but now i just finished. found a perfect marker pen, the perfect length to support the card. I hade to bend it up a couple of millimeters, and no flickering yet ;)
kcodyjr: hey Urigeller23 welcome back again
kcodyjr: that's two coincidences in one day
Urigeller23: (: indeed
gustaf2: if they only could make silent computers...
gustaf2: could only*
kcodyjr: umm, they can
Urigeller23: watercooling..
kcodyjr: that was itself being a PITA, the thread was before you came in
kcodyjr: but it can also be done without it
Urigeller23: alright (;
kcodyjr: it means sacrificing performance and small size, you need big honkin' passive cooling and relatively low clock speeds, cpu and gpu
gustaf2: yeah..
kcodyjr: prescott core chips were impractical for it, but the newer core 2's are getting back within reason... but it's even easier to do with an older northwood based p4
chithead: and passive cooling goes best with an antec skeleton case...
gustaf2: i might seriously consider that for the next computer
gustaf2: I have an antec case ;)
kcodyjr: actually yeah those cases look COOL ;)
gustaf2: but not skeleton..
kcodyjr: but that's a good point; if you're 100% passive then yes, you want an open air case; if you have just one nice quiet fan, then you want enclosed so you can channel airflow to maximum advantage
gustaf2: yeah i have a fan with a 3-step regulator. on the slowest level, it's practically noiseless
kcodyjr: Urigeller23, i found my problem shortly after you left... i wasn't initializing the copy of the pointer to the driver struct. so i really wasn't claiming the resources. doh!
Urigeller23: ouch
Urigeller23: explains it quite well, also (;
kcodyjr: now there's a new segfault. after mouse init. which is a good sign...
gustaf2: and then I have a seasonic power supply of course ;)
kcodyjr: you know, my two quietest machines are dells?
gustaf2: no way they meet the silence of my machine (at least not at the cost of the performance) ;)
kcodyjr: the precision 390 is dead silent, and the dimension 8250 nearly so
gustaf2: but then I have 4 hdd's. that's the only noise i hear..
kcodyjr: the 390 has twin sata's, 500Mb each
kcodyjr: also has the radeon hd 2400 xt, passively cooled
gustaf2: I've "heard" some new dells, and yes, they perform very well. like the sun workstations. finally the industry realises that we do use computers all day long and are rather tired of bull dozers
kcodyjr: the 8250 has a small fan on the radeon 9600 agp, if i remember right, and the main system fan (combined chassis/cpu fan) is starting to show some bearing noise after 6 years
kcodyjr: i'm calloc'ing a fake framebuffer at the moment; i figure i've torn apart the base driver API if i can reproduce Xvfb with a driver containing "null" hooks
gustaf2: but you don't vote with your wallet for OSS-"approved" hardware, and you don't get exactly what you want, and you don't plug in a lot of hdd's in normal desktops. those are my conserns for not buying one
airlied: kcodyjr: the LUTs are how color correction is typically done
kcodyjr: airlied, can i actually count on correction being doable that way, or must my abstraction be prepared to do it by other means for odd hardware?
airlied: kcodyjr: depends on what you are trying to support, most modern hw seems to have luts.
kcodyjr: gustaf1, actually the only thing i -had- to replace on the 390 was the graphics card. i chose to add the xonar d2x
kcodyjr: airlied, what i'm trying to support is still very much in question; the idea would be to support whatever the abstraction can naturally be supported upon
gustaf2: you're discussing color correction? *listening*.. last time I checked, X had none (Win and OSX has :/ )
kcodyjr: i'm thinking a flag will suffice; if correction isn't being achieved transparently via carefully crafted LUTs, then set a flag and the driver can either deal with it or leave it linear
kcodyjr: gustaf2, bringing it up, because i'm playing in a space which cares, that's all
gustaf2: I care too ;)
kcodyjr: and personally i care. it bothers me greatly that i don't have inline gamut normalization, as well as inline gamma correction for video streams
kcodyjr: and it bothers me greatly because i have a monitor with a rather nonlinear native response curve
gustaf2: my S-IPS monitors will not show their greatness until I can setup X to match their color profiles neither... but I've given up on that.
gustaf2: non-linear native response curve? omg, i might have to google for that one.
kcodyjr: heh
kcodyjr: it looks gorgeous in the midrange but slews much too sharply at the top and bottom
airlied: wierd I thought we had some util like xicc for setting color profiles
airlied: or xcalib maybe
kcodyjr: airlied, i wasn't aware of it. how does it work? carefully crafting the LUTs?
kcodyjr: seems gentoo is aware of it. checking it out now.
airlied: kcodyjr: converting ICC profiles to LUT is well defined I suspect
airlied: I think randr can do change gamma stuff
gustaf2: airlied: xcalic and those, at least when I played with them half a year ago, was heavily broken, and I got none of them to work at all. I don't think they work for X >= 7 and they get upset with randr etc etc
kcodyjr: airlied, seems like it ought to be
kcodyjr: hm. gustaf2, randr is heavily involved with crtc programming which is also where LUT setup happens, i can see those changes breaking things
gustaf2: yeah. so until this works, we have nothing, since we're in the middle of a limbo, where randr doesn't do it, and xcalib (and those) don't do it ;)
airlied: it can't be that hard to do, randr exposes the LUT over protocol
kcodyjr: i think we're still missing broader consideration of the color data path though
kcodyjr: we need the ability to force the windowing/output system to neutral to provide an image and instructions for calibrating the display's hardware controls
airlied: really you could do it better with a compositing manager
airlied: the hw control isn't fine grained.
airlied: the overlays can also usually have different gamma curves
kcodyjr: and need to, since often video is expecting a different native gamma than the computer monitor is giving
kcodyjr: but that opens the can of worms when you don't have an overlay; now it's necessary to do the correction inline
kcodyjr: which brings us to a compositing manager that's aware of source and target gamma
kcodyjr: and able to quickly compute dynamic LUT's
airlied: or you get to do it in the fragment shader of the movie player
gustaf2: uh
gustaf2: so only movies get correct color, and the rest of the system not? ;)
kcodyjr: which is really the same thing, just a question of which piece of the puzzle is in control
kcodyjr: there's a point gustaf2 has there, even inline with the movie player there isn't enough data to do it in a single conversion pass
kcodyjr: going that way, at best there's two conversions; from the stream's native to some neutral standard (probably sRGB at 1.0), and then a correction for the target display
gustaf2: please just give me something like: xrandr --output DVI-0 --color-profile mymonitor.icc ;)
kcodyjr: actually i was thinking more like ""
kcodyjr: often the monitor-specific icc profile is just a dump of what's in the EDID data ;)
kcodyjr: unless there's really more data points in the .icc file, there's no point
gustaf2: well, that doesn't mean it's correct
kcodyjr: also true, but if the mfr flubbed that, likely the .icc file isn't great either, so you just have to calibrate by eye
gustaf2: you might have adjusted a profile (with a color adjustment tool), and then you sit there with your perfect .icc and don't know what to do
gustaf2: there are those usb-things you can buy.. perhaps you've used one in win/mac and it has givven you a .icc. what then?
gustaf2: then you're stuck. stuck I tell ya.
kcodyjr: i haven't used them, but if you mean a usb-based display device, it's really not the point what loads the color profile or what format it comes in
kcodyjr: what's at issue is how that data gets applied, and when in the rendering process this happens
gustaf2: icc is a standard, perhaps _the_ standard..
kcodyjr: it's just a file format
gustaf2: and it should be applied somewhere in X (and for god sake not in some shader app of a movie player or what not).
gustaf2: my entire gnome desktop (or kde) should get it. not just some program here or there.. but how to get a program to show color corrected output, I dunno... RGB (sRGB) isn't correct per se, from what I know, but any jpeg viewer should be able to show a jpeg file with embedded color info, correctly. in my dreams anyway.
gustaf2: well, gotta sleep now. nite.
kcodyjr: sounds like a graphic designer to me
benh: airlied: ping
airlied: benh: pong
benh: airlied: hoy !
benh: airlied: so I have this .28 patch that fixes >32-bit physical addresses which of course is broken on .29 :-)
benh: airlied: mostly a proof of concept cleaning the split of drm_map vs. drm_local_map
benh: airlied: what should I work on for a proper "upstreamable" variant ?
benh: airlied: drm git ? some branch ? .29 ?
airlied: benh: current Linus is probably good ernough
benh: airlied: ok
benh: airlied: it seems GEM/TTM whatever is in kms adds a whole layer of breakage
benh: airlied: but I'd rather let you guys fix that ;-)
benh: allright, I'll do something some time this week, and send it to you
benh: airlied: then I'll go back to fixing the busID / PCI Domain crap
benh: airlied: I have some preliminary patches for libdrm & the DRM that bump the library interface version... the kernel sees that "newer" library and enables domain support properly
benh: airlied: still have to iron out a problem with 2 radeons in 2 different domains and once that works, I'll send you all the patches
airlied: benh: GEM is intel only for now, they don't even have PAE working yet
benh: airlied: ok, well, they'll have a similar problem anyway, so I'll let them deal with it
benh: airlied: though the patch has to change drm_map to drm_local_map in many DRM internals, and so I -have- to fix at least some of the stuff I don't care about so it compiles :-)
airlied: benh: submit a first patch with just the renames in it
airlied: then a second with the changes.
benh: airlied: I'll see what can be done, it's a bit intricated
benh: airlied: but yeah, that's sort-of the idea
dmb: whats the big difference between xinerama and big desktop?
mjr: xinerama is a particular way to implement a multimonitor desktop
mjr: largely replaced by others
dmb: i was reading that it is becoming depracated in favor of xrandr
mjr: also, an X extension whereby an application can query information on the physical monitors comprising the desktop; in this capacity, it will live on
mjr: the new methods provide the same api
dmb: but it seems like none of the other methods work well when one monitor has a higher resolution than the others
chithead: x is built around the idea of rectangular desktops
mjr: yeah there's some friction there
dmb: i was using amdcccls big desktop, but i just couldn't deal with things that got moved to areas where i couldn't see
dmb: i'm guessing amdcccle uses randr?
dmb: (bigdesktop)
chithead: I use xf86-video-ati without such problems
dmb: chithead, do you have 2 monitors with different resolutions?
dmb: i would use xf86-video-ati, but it likes to hard lock whenever using opengl applications for some time
chithead: yes, a 1280x800 laptop panel, and external displays at resolutions between 1024x768 and 1680x1050
mjr: amdcccl sounds like the proprietaary driver from a quick google
chithead: I had lockups too, but these went away after disabling tickless kernel
mjr: oh, we already covered that
dmb: mjr, it is
dmb: mjr, how can i find out if my kernel is tickless?
dmb: looks at the config
kcodyjr: grep TICK .config
dmb: CONFIG_SCHED_HRTICK=y
dmb: CONFIG_TICK_ONESHOT=y
dmb: i guess it is enabled
dmb: but the driver should still work
dmb: with a tickless kernel
chithead: dmb: CONFIG_NO_HZ
dmb: CONFIG_NO_HZ=y
dmb: does that mean its disabled?
chithead: NO_HZ=y means tickless kernel is enabled
dmb: oh
EruditeHermit: bridgman_: where do you live that is so far away from civilization?
EruditeHermit: and is an AMD office located that far into the woods?
EruditeHermit: lol
EruditeHermit: or do you work from home
bridgman_: I work from work and from home ;)
bridgman_: work is in Markham, north of Toronto but still very built up
bridgman_: home is 70 Km east of work, in the middle of nowhere
bridgman_: I used to live in the city and moved out
bridgman_: very happy here other than the connectivity
bridgman_: and the snow
bridgman_: and the snow
bridgman_: did I mention the snow ?
spstarr: yeah bridgman_ is really close to where I work too :-)
spstarr: snow
spstarr: bridgman_: i think we should add a snow GL routine, much better than fog, you know ;-)
spstarr: since snow can be transparent depending on the precipitation type (sleet/wet snow, vs snow) then it comes down to temperatures
bridgman_: I though that was the "white screen at startup" bug, at least that's what I've been telling people
spstarr: hehe
bridgman_: you know, "it's not a white screen it's a polar bear in a snowstorm" ? what you said while holding up a blank sheet of paper when you were goofing off in art class ?
EruditeHermit: bridgman_: thats a long commute
EruditeHermit: do you do it every day?
EruditeHermit: why did you move so far away?
EruditeHermit: prefer the countryside