[06:28] *yawn* [06:33] tjaalton: Morning. [06:36] wgrant: hi there [06:44] * wgrant hopes his multi-finger tapping fix will actually work fairly well. [08:08] heya [09:13] bryce_: hi, you got the timber you were looking for?-) [09:15] tjaalton: yep... uhh how'd you know I went and bought wood today? [09:15] bryce_: because you told me :) [09:15] okay :-) [09:15] yeah, spent the whole day working on the new desk pieces for my office [09:16] and worked a bit on building a new bookcase [09:16] the latter of which necessitated going out tonight and buying a new board (the one I'd been working was too badly warped) [09:19] sounds like fun, and a lot of work :) [09:19] yep [09:20] I should take some photos [09:20] essentially it's a multi-window window sill, but it's going to double as a fancy multi-monitor stand as well [09:20] + cat sleeping platform [09:24] hehe [09:26] does anyone feel like testing and confirming https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/282387 ? :) [09:26] Launchpad bug 282387 in xserver-xorg-input-evdev "scrollwheel emulation breaks after suspend with 2.6.27-7" [Undecided,New] [09:28] or better yet, fixing it ;) [09:32] just took some photos - http://bryceharrington.org/Photos/Woodworking/ [09:34] bryce_: nice :) [09:37] you probably can't tell from the photo that one of the uprights is screwed up, but we went and got a replacement board tonight. I'll have to re-router it and stuff, but it'll fit a lot better. [09:42] bryce_: I was thinking of adding the support for multiple profiles to the xrandr capplet (for Jaunty) [09:43] e.g. office, home and other profiles will give direct access to different configurations which will be applied with only 1 click [09:43] tseliot: nice, that should tie in well with what soren had planned [09:44] bryce_: do you know where I can find Soren Sandman? [09:44] I think that my recent work could be reused for this purpose [09:45] but of course, if my changes are not accepted upstream, my work is not that useful [09:46] tseliot: well aside from emailing him, I don't know a better way to reach him [09:46] he seems not very gregarious; I've had trouble getting in contact with him [09:47] (even when I was with him in person!) [09:47] heh [09:47] I sent him an email but of course I didn't receive a reply [09:47] tseliot: btw, I was thinking I'll bring you the tablet when we see each other at google in december - save on shipping costs. :-) [09:48] bryce_: that might cause me some problems with my baggage though [09:48] howso? [09:49] if you let me know how much the shipping is I will pay it in advance [09:49] the tablet is about the size/weight of a children's book [09:49] that's bacause I will carry my baggage with me [09:49] ok, if you prefer that I'll send it that way [09:49] and there are limitations to the size and weight [09:50] ok, let me know how much it is via email [09:50] thanks [09:51] * wgrant will be glad to finally see some Ubuntu people at UDS. [09:51] I will fly from Brindisi to Rome, from Rome to Frankfurt and from Frankfurt to San Francisco. I doubt that they wouldn't lose my baggage [09:52] wgrant: we'll have some time to talk there [09:52] :-) [09:52] tseliot: Yep. [10:31] bryce_: looks nice [10:38] is there anything worth doing/reporting if a given machine doesn't autodetect the right resolution for a monitor? [10:39] I restored an old xorg.conf on the laptop in question to get the guy working again [10:39] short of doing an xrandr --addmode every boot I don't know of another way to unmake the fail [10:39] Ng: can I see both xorg.conf files? [10:39] tseliot: I don't think I can get hold of them today, I don't see the person in the office [10:40] Ng: ok, no problem [10:40] I could probably go and check the DDC/EDID info of the monitor, I'm just wondering if we have a way to override that, assuming that's what was wrong [10:41] EDID quirks, yay. [10:42] * Ng also curious why X detected the DPI of a macbook air incorrectly, I thought apple hardware was among the few which were pretty much guaranteed to report correct values :/ [10:43] xdpyinfo | grep dots showed 96, but it's actually about 113 [10:43] Ng: are you sure that's incorrect detection and not GNOME just forcing 96 dpi there? [10:43] Ng: did you look in the Xorg.0.log? [10:44] seb128: no, I didn't think gnome changed X's setting, it just goes with its own default of 96? [10:44] Ng: did you use the xrandr capplet? [10:44] nope [10:44] I just grepped the output of xdpyinfo, I always thought that returned a raw calculation of the resolution against the reported physical dimensions [10:44] I didn't look recently but in hardy once a xrand config was written g-s-d was forcing 96 dpi when applying it [10:45] Ng: look to the xorg log [10:45] ok [12:05] * Ng kicks fdo gitweb. I want to see evdev's history dammit! [12:05] Ng: try cgit [12:05] ooh, nice [12:06] usually works better than gitweb [12:06] apparently my scrollwheelemulation thing was fixed today, so I'm looking to see if it's a patch I can pull into our evdev package and rebuild easily [12:07] i guess that would be http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/diff/?h=evdev-2.1-branch&id=b4fcb825fc989131c399e3473576f539a81f3aac [12:15] although pulling HEAD of evdev-2.1-branch might be easier [12:16] if needs be I'll do that, but if I can isolate it to a single patch then it'll be easier to persuade someone to upload it to ubuntu ;) [12:51] hmm, well a quick initial test suggests that that patch does indeed fix things [12:52] Ng: what bug do you have? [12:53] https://bugs.edge.launchpad.net/evdev/+bug/282387 [12:53] Launchpad bug 282387 in xserver-xorg-input-evdev "scrollwheel emulation breaks after suspend with 2.6.27-7" [Undecided,New] [12:53] but I think it's breaking some text selection stuff [13:02] aha, upstream say it should be b0737bdbd1f6e601eb4984b6f4cb49279190984ca [13:24] * Ng apologises for being useless at operating git and fdo, but I can't find that commit in the thing I cloned [13:24] I grabbed master of xf86-input-evdev [13:25] Is there an "evdev-2.1-branch" branch? [13:26] I think so, but I don't know how I would get it [13:26] "git branch -r" lists the branches [13:26] origin/evdev-2.1-branch [13:26] though I would assume "git show b0737bdb" would work regardless of your branch [13:27] ah yes, it does [13:28] james_w: how would I get the 2.1 branch out of what I cloned? [13:28] upstream asked me to test git tip anyway [13:28] huh [13:29] I always get this bit wrong, I've never managed to get it to do what I want [13:29] (I used "git clone git://anongit.freedesktop.org/xorg/driver/xf86-input-evdev") [13:29] heh [13:30] I think "git branch --track evdev-2.1-branch origin/evdev-2.1-branch" [13:30] then "git checkout evdev-2.1-branch" [13:31] and that should magically mutate the current working tree into that branch? [13:31] I think so [13:32] ok, I'll give that a go, thanks :) [13:32] the branch sets up a local branch to follow the remote one I think [13:32] (why can't the world just use bzr? ;) [13:32] then checkout shows you that branch [13:32] if only :-) [13:32] Ng: that's the same commit that jcristau pointed out, just from a different branch [13:33] ah [13:34] well I hope this works better than a build of master does (building and copying over evdev_drv.so caused X to instantly crash and after rebooting the scrollwheel emulation didn't work at all ;) [13:37] damn, it's still completely broken, I can't even select text [13:42] Ng: do you get events from the button? [13:44] tjaalton: so watching with xinput test and trying to drag select some text, it seems like the button press and release both come together after the motion (this is with git evdev) [13:45] Ng: xev should release what happens [13:45] I don't have a baseline comparison of it working to know if I should see "press, motion, release" though [13:45] uh [13:45] reveal [13:46] I had a simlar problem when I was testing the properties backport [13:46] xev shows the same, the press and release both happen together after the motion (with the same disclaimer that I don't have a normal set of results to compare to) [13:46] I only got a button-up event from the left mouse button [13:46] or something like that [13:47] gar, maybe I did something wrong with the build, xinput is showing no properties for the trackpoint [13:48] but it doesn't look like there are any configure options to set or anything [13:48] well, perhaps you need to patch out the ifdef's which check for properties support? [13:48] like the package does [13:54] tjaalton: this would be the dont_check_abi patch? [13:56] Ng: yep, but might be that master uses some other method to determine if properties should be enabled [13:56] just about to test with that patch applied [13:58] yeah, that should apply just fine [14:02] it does and that gives me properties. too many almost, I see "Wheel Emulation" and "Evdev Wheel Emulation", but I can't make either work [14:02] I suspect this may be beyond my diagnostic abilities ;) [14:04] hehe [14:16] tjaalton: it's probably not beyond yours though, and you have a trackpoint ;) [14:16] Ng: well, I've never actually used the feature, but maybe I should?-) [14:17] I was also surprised to know that tapping the tracpoint should generate some event [14:17] tjaalton: i think it's good enough that I wouldn't even consider another laptop which doesn't have a middle mouse button [14:17] (which means I can only ever buy a thinkpad, because nobody else has them ;) [14:18] hmm yeah I've seen talk of tapping the trackpoint before, but I'm not sure, it doesn't feel like there's a switch in there [14:18] xinput set-int-prop "TPPS/2 IBM TrackPoint" "Wheel Emulation" 8 1 [14:18] xinput set-int-prop "TPPS/2 IBM TrackPoint" "Wheel Emulation Button" 8 2 [14:18] xinput set-int-prop "TPPS/2 IBM TrackPoint" "Wheel Emulation Y Axis" 8 4 5 [14:18] that should enable it [14:18] although the device is different if you have the touchpad enabled [14:19] something related to thinkpad_acpi I guess [14:19] tapping I mean [14:19] * Ng asks ##thinkpad ;) [14:25] well well well [14:25] echo -n 1 | sudo tee /sys/devices/platform/i8042/serio1/press_to_select [14:25] tapping it now makes it send button 1 [14:26] heh, ok [14:39] but now I'll try to make the server crash [14:48] bah, evdev refuses to init the joysticks I have [16:01] seb128: fwiw http://paste2.org/p/86640 is the xorg.log from the macbook air [16:01] I've just noticed that X says the same "DPI set to (96, 96)" for my laptop, and it's 127dpi [16:02] but I think that's too early for gnome/xrandr to be doing it, so maybe X is just defaulting to that these days [16:03] to track down who (gnome or driver) is busting things, it might be useful to start a bare X server and see what xdpyinfo says there [16:04] the default is 96 nowadays [16:04] actually for some time now, but [16:04] that's such a shame :/ [16:04] yeah, but if the driver gets the actual size from the monitor it uses that [16:05] (used to be 75) [16:05] yes [16:05] I understand the reasons why setting it to the reported value is potentially bad, but I wish we could make it work somehow, it makes font rendering so much nicer [17:15] hey guys, I got some good news about -fglrx [17:17] you'll stop shipping it? :) [17:20] maybe some day ;-) [17:27] ok, so what is it then :) [17:28] +? [17:29] i guess it's finally ported to 1.5? [17:30] probably so [18:04] tjaalton: yep, we should be getting a 1.5 version today [18:34] grmbl [18:34] (gdb) p sizeof(xGetDevicePropertyReq) [18:34] $14 = 40 [18:36] (gdb) p sizeof(req->property) [18:36] $19 = 8 [18:36] OOH [18:36] wgrant: see above. sizeof(Atom) should be 4, not 8... [18:43] wgrant: reported to whot on #xorg-devel, let's see what's next :) [19:01] bryce_, a public 1.5 version, or private? [19:01] "for inclusion in Ubuntu 8.10 today" [19:05] interesting. it skipped private beta then [19:05] they had asked for some changes to the packaging scripts for 8.10 last week, but I assumed that was in preparation for a private beta [19:38] bryce_, so assuming they follow through on this, i'm assuming i'm in the clear to upload it, no need for FFe's at this point since it's a pretty well known regression right now? [19:39] superm1: that's correct [19:39] (downloading now) [19:40] oh there's a link posted? [19:41] no [19:41] bryce_, ah okay. well perhaps you'll just want to do the upload for it yourself then when you've taken a look at it. [19:49] bryce_: if all works well, please let me know so that I can remove the update-manager fglrx->ati transition [19:50] superm1: it's been a while since I've done an fglrx upload, so esp given this is last minute I'd definitely appreciate your eyeballs on it [19:52] superm1: do you have the fglrx-installer update process documented somewhere? I wouldn't mind giving it a go for the experience [19:52] bryce_, okay so things have changed the way that you do fglrx uploads nowadays [19:52] bryce_, more or less take the .run from AMD, and do a --buildpkg Ubuntu/source [19:52] it will build a diff.gz, orig.tar.gz and dsc for you [19:53] dpkg-source -x that dsc, dch -e to update the new changelog entry [19:53] make sure to mark out any bugs that get closed with it [19:53] and then debuild -S, throw it in a pbuilder/sbuild and make sure it churns out functional debs [19:53] if so, upload the .changes [19:54] some of this is documented in README.Debian in debian/ of the current source package [19:55] ok cool, I'll give it a shot [19:57] if you've got to make changes to anything in debian/, try to let me know since i'm the only one that can sync it to the git tree that AMD pulls from to keep future uploads in line [19:57] will do [19:58] if you've got some ideas how we can improve that, i'm open to finding better ways to automate that [19:58] and allow others to do uploads etc [19:59] sure, docs are usually a good starting point. I'll see about making sure what you've listed above is included in the README.Debian [20:04] http://github.com/pieter/git-bzr/tree/master seems to be a good idea. perhaps make a bzr branch that's owned by ~ubuntu-core-dev, and whenever changes are necessary, they can be added there. perhaps can then go as far as getting a cron job on the git server and asking it to nightly merge stuff that happens on the bzr remote [20:20] superm1: hmm, I ran `$ ati-driver-installer-8.543.2-x86.x86_64.run --buildpkg Ubuntu/source` on a hardy system and got the warning: Unable to resolve libstdc++5. Please manually install and try again. [20:20] I'll re-try in my intrepid chroot [20:21] bryce_, you'll need libstdc++5 available [20:21] it's probably still in universe [20:22] superm1: does that driver work with the new xorg abi? [20:22] huh, not at all happy about being run in the chroot [20:23] tseliot, yeah it is [20:23] great [20:23] ah, just missing cdbs [20:23] bryce_, it really should be resolving those dependencies automatically [20:24] bryce_, i'm a bit surprised it's not [20:25] doing a $ sudo apt-get build-dep fglrx-installer [20:25] my chroot is pretty minimal so not a surprise I'd need to install stuff. this needs a couple dozen packages [20:26] interestingly, it's pulling libstdc++6 rather than 5 [20:26] * bryce_ -> lunch. bbiab [20:28] the expectation has been that you've got a full system when you "assemble" the source package, but then a chroot when you build the source package to a binary package [20:28] and it grabs the missing pieces in both cases with those expectations [20:44] hello, will the radeonhd driver be updated to 1.2.2 in intrepid? or is it too late for that? [20:48] wst: we're a ways past the point where we do upstream version syncs. [20:49] wst: individual patch pulls are possible where they fix specific bugs though, but it's getting fairly late even for that [20:50] yes, 1.2.2 seams like a pretty big change, but a lot of popular new chipsets are supported by it [20:51] well I guess too bad that it is released only now... [20:53] superm1: out of curiosity, does the .run install stuff to your system? I'm curious why it needs sudo privs [20:53] bryce_, yes it does [20:53] bryce_, it installs things necessary for building [20:53] eg cdbs, libstdc++ [20:54] you can look at it's source (--extract on the .run), in packages/Ubuntu/ati-installer.sh [20:55] it's been put together the way it is so that if someone goes to AMD's website, downloads it, they can run --buildandinstallpkg on a desktop system and have it do everything [20:55] that's fine, just wanted to make mention of this in the README.Debian [20:55] --buildpkg Ubuntu/source is a bit of a corner case [20:55] ah yeah [21:11] superm1: the amd package seems to only include the ubuntu changes up through 8.512 [21:21] jcristau: Erm, really? [21:23] superm1: ok I got the 512->532 changes merged in cleanly [21:25] wgrant: does 'typedef unsigned long Atom;', so I guess if you s/Atom/CARD32/ in XIproto.h, it'll all work... [21:27] (hopefully) [21:27] jcristau: I never bothered to check that, as everything else worked fine... oops. [21:28] I suppose I'll need to rebuild libxi as well... [21:28] yup [21:28] wgrant: yeah, i should have thought of that sooner... didn't occur to me until i got around to looking at it in gdb on amd64 today... [21:28] Any response from #xorg-devel? [21:29] not yet. but, still early in .au [21:30] Pfft. I'm here. [21:31] heh, right :) [21:32] * wgrant rebuilds libxi [21:33] (intrepid-amd64)fujitsu@fisto:~$ ./getprop 3 "Device Enabled" [21:33] result: 0 [21:33] type: integer [21:33] format: 8 [21:33] nitems: 1 [21:33] bytesafter: 0 [21:33] 1 [21:33] Awesome. [21:34] jcristau: Thanks! [21:34] wgrant: np. you did most of the work :) [21:34] ... but I missed the most obvious thing. Thus I lose. [21:36] Why didn't that break anything else, I wonder... [21:37] no other struct has Atom fields [21:38] Oh. [21:39] Is Atom actually meant to be used in that context? [21:43] apparently not, since it's size is not consistent [21:43] it's fine in a library, not so much in the protocol [21:43] Right. [21:50] Looks like master is affected. [21:50] Hmmm. [22:07] How close is the new fglrx? [22:08] wgrant: so close if it were a snake it'd have bitten you [22:09] unless it was a nice snake that didn't bite people [22:09] I've reviewed the packaging changes, completed a successful build, etc. and am just now doing the final doublechecking of changelog and stuff [22:10] People are currently suggesting on ubuntuforums that people downgrade to Xorg 7.3, and I'm wondering if we should save those users the trouble (as it was just suggested to new people a few minutes back). [22:10] wgrant: yeah tell them to hang on [22:10] Will od. [22:10] if they downgrade they'll just be pissy in a couple hours when they want to test this new one [22:11] Yep. [22:12] Was it Mandriva who released recently with 7.3 because of this? [22:13] bryce_, do you know when are they going to put this as "public" on the website? [22:15] superm1: probably you should talk to your amd contact for a date for that [22:15] wgrant: yep [22:16] ok, uploading [22:16] They'll be slightly irritated. [22:16] Yay! [22:16] bryce_, yeah, was just curious if they gave you one. I'm sure people from fedora will ask how we got it [22:16] etc [22:16] superm1: I didn't get any information regarding public releases [22:17] I can infer some things based on the wording of the email, but probably better you get it straight from official sources [22:17] Um, so it's sort of embargoed, except that everyone will know about it when we release it? [22:19] Nobody running amd64 here? [22:20] not on a regular basis wgrant, but if you need another test, i can spin up another live disk if you need [22:20] I can't speak to that. We've been given permission for including it in 8.10 given our deadlines [22:20] bryce_: Ah. [22:20] as long as it's another simple one [22:20] Argh, the amd64 build missed publisher, while i386 made it. [22:20] superm1: Just two packages this time - libxi and xserver-xorg. [22:20] wgrant, what's the test this time? [22:21] superm1: Same as last time. xinput list-props on some device should no longer fail. [22:22] wgrant, do I need a more updated live disk again? or can i use the same one and just rev those two packages? [22:23] superm1: How old is it? I don't recall... [22:23] wgrant, a couple of days. probably friday night? [22:23] If it has Friday's new xinput and co., it's fine. [22:24] well if not, it won't hurt to update other stuff too. so xinput, any others? [22:24] If there is a newer xinput, it will pull in the rest of the stuff it needs. [22:27] You'll need http://launchpadlibrarian.net/18543279/xserver-xorg-core_1.5.1-1ubuntu4~wgrant1_amd64.deb and https://edge.launchpad.net/%7Ewgrant/+archive/+files/libxi6_1.1.3-1ubuntu5~wgrant1_amd64.deb [22:27] okay. i'll let you know what i see [22:27] Thanks. [22:29] (the server one shouldn't be strictly needed, Atom should always be 32-bit server-side afaict) [22:30] jcristau: Oh, so there are different definitions? [22:31] # ifndef _XSERVER64 [22:31] typedef unsigned long Atom; [22:31] # else [22:31] typedef CARD32 Atom; [22:31] # endif [22:31] Ah. [22:32] How odd. [22:32] yeah. i don't want to know where that comes from. [22:47] wgrant, "xserver-xorg-core breaks xserver-xorg-input-evdev". guess i gotta update that too :) [22:48] superm1: Sounds like that's a CD from before the transition. [22:48] Yep. [22:48] jcristau: Any objections to me uploading a fixed x11proto-input? [22:49] wgrant, yeah I can see all sorts of options now [22:49] in xinput list-props [22:49] appears to have worked [22:49] superm1: Do they have failures? [22:49] Rather than fetch failures? [22:49] Er. [22:49] Do they have *values* [22:49] wgrant, yeah they do [22:49] you want a pastebin? [22:49] Excellent. [22:49] No, thanks. [22:50] okay, glad to help. [22:50] I'm glad to finally have that resolved. [22:52] wgrant, what about the changes that turn on stuff like circular scrolling and what not? [22:52] (er maybe those are in already, and i'm just on this old disk) [22:53] superm1: I never got them into the GUI. [22:53] But you can enable it using xinput easily. [22:53] wgrant, oh that's too bad. still time to try for intrepid? [22:53] RC freeze is tomorrow. I doubt it. [22:53] * superm1 hands wgrant multiple red bulls. [22:54] I have excessive uni work until Friday, unfortunately. [22:54] It's no regression from Hardy, either :( [22:54] right [22:54] bryce_: Can you upload http://people.ubuntuwire.com/~fujitsu/libxi_1.1.3-1ubuntu5.diff and http://people.ubuntuwire.com/~fujitsu/x11proto-input_1.4.3-2ubuntu4.diff, please? [22:55] I can't see the Ubuntu versions in git anywhere. [22:55] wgrant: I can put them on my todo list; lp #'s? [22:56] bryce_: Bug #267611. Should I attach the debdiffs? [22:56] Launchpad bug 267611 in x11proto-input "[intrepid] cannot see touchpad tab in mouse configuration" [High,In progress] https://launchpad.net/bugs/267611 [23:01] bryce_: I've attached them to the bug. [23:01] * wgrant leaves for uni. [23:03] yep, thanks [23:32] hey there [23:32] so bryce_, any idea what's going wrong ? [23:32] looks like X thinks my lappy has only 8bit color depth [23:32] well... I wonder at the depth error message [23:33] yeah [23:33] have you tried forcing it to 32 or something? [23:33] also, did you install this manually or with jockey? [23:33] no, I don't have any xorg.conf around and don't remember the color depth thing from the top of my head [23:33] if the former, maybe try the latter to see if it has a workaround [23:33] jockey doesn't display anything, so that's manual [23:34] "No proprietary drivers are in use on this system" [23:34] stgraber: 'X -depth 24' :) [23:34] and I had a Radeon HD2600 ... [23:34] jcristau: hmm, right, will try that. [23:35] jcristau: fwiw here's the error msg he got http://ubuntu.pastebin.com/f6529441d [23:35] heh [23:35] jcristau: syntax for adding depth in xorg.conf: http://ubuntu.pastebin.com/m17f20e58 [23:37] worked [23:37] so it's X that's a problem detecting my color depth [23:38] I must say I found the colors a bit weird recently but as I don't really have a good sight I probably didn't notice it having switched to 8bit [23:38] depth 24 is the default... [23:42] jcristau: http://ubuntu.pastebin.com/f34a0d549 [23:42] something about this feels quite familiar [23:42] that's my xorg.conf and I had 8bit with that [23:42] so 24bit doesn't seem to be the default here :) [23:43] stgraber: well, that just sounds like fglrx being crap [23:43] not too surprising [23:43] can you post the Xorg.0.log from booting it with 8bit? [23:43] I mean, without specifying the depth? [23:44] I seem to recall coming across a bug like this once before, but have forgotten the specifics [23:44] bryce_: sure [23:47] ok, I just saw the gdm wallpaper with fglrx 24bit now and I can tell you that the color depth was wrong with the radeon driver too [23:47] I though something was wrong but now I'm quite sure of that :) [23:47] fglrx 8bit: http://ubuntu.pastebin.com/f2aeba756 [23:47] mm, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460241 [23:47] Debian bug 460241 in fglrx-driver "fglrx-driver: Does not work unless DefaultDepth 24 is specified in config" [Important,Open] [23:47] radeon: http://ubuntu.pastebin.com/ff9a2067 [23:48] # [23:48] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [23:48] yeah, just saw that. So it's probably completely unrelated (but the colors were broken for sure :)) [23:49] anyway, the issue now is to have fglrx works without needing to add custom entry to xorg.conf [23:49] (well, or add that to jockey if we can't fix it) [23:49] well, if it's in the binary from ati ... [23:49] # [23:49] (II) fglrx(0): Creating default Display subsection in Screen section [23:49] # [23:49] "Default Screen Section" for depth/fbbpp 8/8 [23:49] # [23:49] (EE) fglrx(0): Given depth (8) is not supported by fglrx driver [23:50] doh-yee [23:50] yeah, I wonder what "gives" it that 8 [23:51] aha here's the LP bug: #194963 [23:51] so this is something jockey fixes up -- good [23:52]