[00:39] <ScottK> RAOF: Found a victim/volunteer.  Should be here in a few.
[00:45] <ScottK> afiestas: Welcome.
[00:45] <ScottK> afiestas: meet RAOF (one of the Ubuntu X maintainers).
[00:45] <RAOF> afiestas: Howdie.
[00:46] <ScottK> RAOF: Meet afiestas.  He's interesting in improving the multimonitor experience in KDE.
[00:46] <ScottK> I don't know how much he knows about the video layer, but he's one of the developers that got us a new (working) bluetooth stack in the last cycle for KDE.
[00:46] <RAOF> Sweet!
[00:47] <afiestas> hi
[00:47] <ScottK> The idea is (loosely) the perhaps you two can work on something that we can experiment with in Kubuntu this cycle that would then be ready for upsteam KDE in KDE 4.7 (natty +1 for us).
[00:47]  * ScottK goes to find out if his youngest child drowned in the shower yet or not.
[00:49]  * RAOF wonders if they do that often?
[00:49] <RAOF> afiestas: So, what is your current level of understanding of the multimonitor stack?
[00:49] <afiestas> RAOF: well, my knowlege about video or X is limited to libxrandr, I played with it a kind of xrandr (cli) replacement 
[00:50] <afiestas> also I read a big part of randr specification until the point where the actual specification starts
[00:50] <afiestas> (so I know the basics terms and so on)
[00:50] <RAOF> Superb; you've therefore mastered almost the entirity of the tools available.
[00:52] <afiestas> RAOF: so, what you guys have in mind :o?
[00:53] <RAOF> Basically, to standardise the decisions that currently get made.
[00:53] <RAOF> The blueprint is here: 
[00:54] <RAOF> https://blueprints.launchpad.net/ubuntu/+spec/multimedia-desktop-n-xorg-multihead-defaults
[00:54] <RAOF> Basically, what a DE needs to do is:
[00:55] <RAOF> Have some process which selects for hotplug events.  In GNOME this is gnome-settings-daemon; I presume KDE has an equivalent.
[00:55] <RAOF> When a hotplug event is detected, do something.  This something is dependent upon past configuration:
[00:56] <RAOF> 1) If the user has previously plugged in this device, use the same settings for this device as before.
[00:56] <ScottK> One of the unfortunate things at the moment is that KDE has two: krandrtray and kcm_randr (or something close).
[00:56] <RAOF> ScottK: And, I notice, nothing running in KDM to detect hotplug - this makes plugging in a monitor after boot fail.
[00:57] <afiestas> well, I don't  have clear what would be my first steps in kde+xrandr
[00:57] <RAOF> 2) If the user has previously not plugged in this device, choose the largest possible shared mode, clone the screens, and pop up a quick selection dialog.
[00:57] <ScottK> One of the fun bits is if you do it, as soon as you open kcm_randr, kranrtray suddenly notices the monitor and you go from no tools helping you to two.
[00:58] <afiestas> from what I've seen so far, I will rewrite everything from scratch, and it should not be difficult
[00:58] <afiestas> RAOF: would not be better to show the selection dialog first?
[00:58] <RAOF> It sounds like the first thing to do would be to get rid of one of the two tools :)
[00:58] <ScottK> No one will object I don't think.  The current KDE code could be described optimistically as "under maintained".
[00:58] <afiestas> change the resolution sounds annoying :/
[00:59] <RAOF> afiestas: What monitor do you show the selection dialog on?
[00:59] <afiestas> primary
[01:00] <RAOF> Which one is the primary display?
[01:00] <afiestas> it is decided by the driver iirc from xrandr 1.3 and up
[01:00] <RAOF> Also, how do you know the user can actually *see* the primary display - laptops in a docking station suffer from this problem.
[01:01] <RAOF> You can also explicitly set a display as primary; that's one of the things the DE tools should expose.
[01:01] <afiestas> well, then we should detect if a dock station is plugged
[01:01] <afiestas> anywya I'm not a usability expert... so I can't say 
[01:01] <afiestas> but from my user point of view, I don't want unexpected resolution changes
[01:02] <afiestas> (osx extends the desktop iirc)
[01:02] <RAOF> There are all sorts of similar corner cases.  Basically, the idea with cloning is that you can *guarantee* that the user can see how to select what they want.
[01:02] <RAOF> As long as they can see one of their outputs, at least.  But if that constraint isn't satisfied, they've got other problems :)
[01:03] <afiestas> so, when you connect your laptop to a docking station, the lvds is turned off?
[01:03] <afiestas> (just curious)
[01:04] <RAOF> Not for *me*.  But many people shut the lid (which *doesn't* disable the display, just blank it) when they put their laptop in a docking station.
[01:05] <RAOF> It would be perfectly reasonable for you to decide that KDE should have a default of “extended desktop”.  The participants in the UDS session decided that cloning was the best compromise, but if you work around the corner-cases, extending can make sense, too.
[01:06] <RAOF> Also, this behaviour should only be for monitors which you haven't already configured; if you plug in a monitor and then set extended desktop, next time you plug it in the desktop should be extended, not cloned.
[01:08] <afiestas> RAOF: maybe atm since we don't hnave anything to work on, we may agree on where and how save that informatio
[01:08] <afiestas> *information
[01:08] <afiestas> I know that gnome is using some kind of not docummented xml, right?
[01:08] <afiestas> wouldbe nice if we can unify that
[01:08] <RAOF> Right.  ~/.config/monitors.xml
[01:08] <RAOF> Hm.
[01:09] <RAOF> I wasn't thinking of a fd.o standard, but it does make sense.
[01:09] <afiestas> yes, would be awesome
[01:11] <RAOF> Well, ~/.config/monitors.xml has a version field, and an appropriate name :)
[01:11] <RAOF> Where does KDE store such information?
[01:11] <RAOF> (Or does it?  I've never had anything but trouble with multi-head in KDE)
[01:11] <afiestas> and about the different behaviors, I'm ok with implementing yours always that they're the GNOME's too
[01:11] <afiestas> it doesn't afaik
[01:12] <afiestas> Lubos implemented "Set this as default settings" but nothing to care of
[01:14] <RAOF> Ok.  Well, reading from/writing to ~/.config/monitors.xml seems like a reasonable first step.
[01:15] <afiestas> yes
[01:15] <afiestas> well, before we've to catch up :p
[01:16] <RAOF> There should probably be a shared library extracted to do that, at the same time as I work out how to identify TVs, projectors, etc.
[01:17] <afiestas> we can identify them with the EDID in theory
[01:17] <RAOF> Hah!
[01:18] <RAOF> Yeah, that's a nice theory :)
[01:19] <RAOF> You don't get “I'm a TV” out of the EDID, though, at least as far as I'm aware; you get model & manufacuter names and modelists and such.
[01:20] <RAOF> That's enough to identify “I'm a TV”, but with a bit of work / lookup tables.
[01:21] <RAOF> So there should be a library which handles the lookup/herustics in a nice way for apps.
[01:23] <RAOF> KDE would in theory be happy to add a dependency on a pure-C library which implemented such an idea, plus handled read/write to monitors.xml, right?
[01:27] <afiestas> yes 
[01:28] <afiestas> even if it is a glib based, a lot of kde features is depending on glib stuff 
[01:28] <RAOF> Oh, really?  I presume gobject is out of the question, though :)
[01:29] <RAOF> I don't think it'd be particularly useful, either.
[01:31] <RAOF> There'd be quite a simple interface; something like pass in an xrandr handle and get “I'm sure this is a TV, and last time it was connected the configuration was $foo” out.
[01:31] <RAOF> *Note: API almost entirely pulled from the top of my head.
[01:35] <afiestas> that would be fine 
[01:39] <RAOF> Send your email address to raof at ubuntu dot com and I'll try to keep you in the loop.  Also, subscribing to the blueprint wouldn't hurt.
[01:46] <afiestas> RAOF: oks
[01:51] <afiestas> emailt sent
[01:52] <RAOF> And received.
[06:19] <jman123> hey guys. having problems under a fresh install of 10.10 detecting correct resolutions (best it does is 640x480 on my 1680x1050 lcd) with an nvidia 9500. i tried installing the nvidia drivers, that doesnt do any better. tried editing xorg.conf: http://paste.ubuntu.com/532148/ to no avail. the new modelines dont get recognised by nvidia-settings. 
[06:20] <RAOF>  /var/log/Xorg.0.log is the price of entry to the debugging train :)
[06:20] <RAOF> Could you pastebin it, please?
[06:29] <jman123> sure
[06:31] <jman123> http://paste.ubuntu.com/532166
[06:32] <jman123> i used nvidia-xconfig a couple of times to make a default xorg.conf
[06:32] <jman123> and mucked around with xrandr trying to get a modeline working
[06:33] <RAOF> So, yeah; as expected, the problem is that your display isn't sending a valid EDID, so the driver has no idea what the valid modes for it are.
[06:34] <RAOF> It _looks_ like your xorg.conf contains a valid modeline, but I'm not sure what arcane supplications the nvidia binary driver requires before it'll accept modelines.
[06:34] <jman123> btw here where my attempts at using xrandr paste.ubuntu.com/532168
[06:35] <JanC> the nvidia driver doesn't support xrandr, I think?
[06:35] <RAOF> Correct.
[06:35] <RAOF> Well, it supports xrandr 1.1, which doesn't do anything very interesting.
[06:35] <jman123> should i ditch the nvidia driver?
[06:35] <RAOF> (In particular you can't add modelines via xrandr 1.1)
[06:35] <jman123> lol
[06:36] <RAOF> You could ditch the nvidia driver.  You'd end up with the nouveau driver, which does support xrandr 1.2, so you'd be able to xrandr-up some appropriate modes.
[06:36] <jman123> the monitor is a VX2235wm connected via DVI
[06:36] <jman123> i also have a VA1912wb connected via VGA
[06:37] <jman123> both viewsonic
[06:37] <RAOF> And the nvidia driver is unable to read an EDID from either; it doesn't get an EDID at all from the VGA monitor, and it gets a corrupted EDID from the DVI.
[06:37] <jman123> why would that be?
[06:37] <RAOF> So, either there's something wrong in the cabling or Viewsonic has failed to correctly write 128 bytes of EDID data.
[06:37] <RAOF> Or, I guess, someone wired up your GPU badly :)
[06:38] <jman123> lol. asus
[06:38] <jman123> so.. what to do?
[06:38] <JanC> you could try with another graphics card if that gets a correct EDID...
[06:38] <RAOF> My bet would be on a corrupted EDID.
[06:39] <jman123> not an ubuntu bug then?
[06:39] <RAOF> Probably not an Ubuntu bug, except in so much as we could possibly handle it better.
[06:39] <jman123> works fine under windows btw, so i sorta doubt its the hardware
[06:39] <RAOF> Windows is special :)
[06:39] <jman123> probably should have mentioned that before
[06:39] <JanC> some monitors come with "windows drivers"
[06:40] <RAOF> Or, rather, Windows contains more / better work-arounds (up to and including special GPU drivers which embed corrected EDIDs for some displays)
[06:40] <jman123> and it did work under ubuntu. i was using 10.04. then after a couple of reboots it refused to see the dvi monitor at all and only had the wrong resolutions on the vga one
[06:40] <JanC> hm
[06:40] <jman123> fubar
[06:41] <RAOF> That's without changing anything in the Ubuntu install?
[06:41] <jman123> it was with stock drivers yes
[06:41] <RAOF> So - it was working fine, and then it stopped working?
[06:41] <jman123> indeed
[06:41] <JanC> you did check the cables/connectors too?  ☺
[06:42] <jman123> yes
[06:42] <jman123> actually.. i did put in a KVM but that was only for the vga monitor
[06:42] <RAOF> What changed between it working and it not-working?
[06:42] <jman123> a reboot
[06:42] <RAOF> Well, the KVM is probably why the driver can't get an EDID from the VGA monitor.
[06:43] <jman123> yeah i forgot about the kvm
[06:43] <RAOF> Far too many KVMs don't wire up the DDC pins.
[06:44] <jman123> ok kvm disconnected
[06:44] <jman123> will a reboot re probe the EDID?
[06:44] <RAOF> Just restarting X should work.
[06:45] <jman123> logging out does that right?
[06:45] <RAOF> Logging out & logging back in again will restart X if you're using a default Ubuntu install, yes.
[06:45] <jman123> ok
[06:45] <RAOF> (Kubuntu does it differently, and exposes fun new sources of bugs because of it!)
[06:46] <jman123> so those modelines i put in the xorg.conf.. why doesnt that work?
[06:46] <jman123> shouldnt it force the screen into it?
[06:46] <RAOF> I'm not sure.  Those options are driver-dependent, and the nvidia driver clearly isn't reading the modelines.
[06:47] <jman123> the log does mention removing each of the modes
[06:47] <RAOF> Yeah.  It's either not finding those modelines you've specified or it's found them and decided they're invalid.
[06:48] <jman123> ok new log after removing the kvm is 532172
[06:49] <JanC> RAOF: is the GDM vs. KDM differences why Robert Ansell made a DM that could work for multiple DE with the functionality separated from the greeter?
[06:51] <RAOF> Partially.
[06:51] <RAOF> Partially it was becase he discovered he could replace GDM with 1/10th the code, while implementing a couple of missing features :)
[06:52] <JanC> well, from what I read, large parts of the gdm source were dead code anyway  ;)
[06:52] <jman123> well is there anything i can do to analyze whats happening here? dont mind reinstalling or whatever as this is a fresh install anyway
[06:53] <RAOF> Does it work any better without the KVM?
[06:53] <RAOF> Oh, I see you've posted the ID for a pastebin.  Right.\
[06:54] <jman123> yes, nvidia-settings now has the correct res for that monitor, still not the dvi one
[06:55] <jman123> oh yeah, sorry about that
[06:55] <jman123> its http://paste.ubuntu.com/532172
[06:56] <JanC> hm, IIRC you can tell the driver to ignore the EDID
[06:56] <jman123> im not chatting from the pc im having trouble with
[06:57] <jman123> heh the question is how i suppose
[06:57] <jman123> i wonder why nvidia didnt chose to make their driver open source
[06:58] <RAOF> I think “Option "IgnoreEDID"” is what you're afther to ignore the... oh.
[06:59] <JanC> well, nvidia released the obfuscated nv driver IIRC  ;)
[07:03] <jman123> empathy is giving me the shits
[07:03] <RAOF> I think “Option "IgnoreEDID"” is what you're afther to ignore the EDID errors on the DVI monitor; I'm not entirely sure what modes nvidia will pick in that case.
[07:03] <jman123> nothing seems to work today :P
[07:09] <jman123> will using that option interfere with the vga monitor though?
[07:10] <jman1234> alright. pidgin.. empathy kept crashing
[07:12] <jman1234> and to answer my own question, yes it will interfere. x now finds no screens
[07:12] <RAOF> Hm, ok.
[07:13] <jman1234> i guess if i use that option i will need to set up modelines for both screens
[07:13] <RAOF> Have you determined whether Windows has been working since Ubuntu startied doing this?
[07:13] <RAOF> Yeah, you will.
[07:13] <jman1234> lemme check
[07:13] <RAOF> It's curious that the driver is now reading a corrupted EDID from the DVI monitor, given it clearly worked in the past.
[07:14] <jman1234> windows works as well as it always did
[07:15] <jman1234> i dont suppose there is any way of viewing a log similar to the xorg log containing EDID's in windows?
[07:15] <RAOF> I'm pretty sure there's _some_ way to extract an EDID from Windows.
[07:15] <jman1234> it'l be a hack
[07:16] <RAOF> Google suggests many options, including http://www.nirsoft.net/utils/dump_edid.html
[07:17] <jman1234> well the nvidia control panel in windows detects the right resolutions first time
[07:20] <JanC> you said that the driver in Ubuntu did that too at first?
[07:21] <jman1234> here is a dump using that program in windows paste.ubuntu.com/532181
[07:22] <RAOF> Yeah, that seems all fine.
[07:22] <jman1234> so both displays are outputting correct EDID's
[07:23] <RAOF> I'm not sure why the linux driver isn't reading the EDID right; it's possible that the Windows driver does it in a more cautious way.
[07:23] <jman1234> 1680x1050 is native for the VX2235wm (DVI) and 1440x900 is native for the other
[07:24] <RAOF> (Sometimes if you try to read each bit of the EDID 5 times and pick best-of-three it'll be more reliable.  True story!)
[07:24] <jman1234> shall i see how the open source lin driver does it?
[07:24] <RAOF> Not a bad plan.
[07:26] <jman1234> im not fussed about 3d and will go with whatever driver works!
[07:26] <RAOF> Then nouveau may well be a better bet for you; it's got better integrated dual-head support.
[07:28] <jman1234> alright i removed nvidia the same way i installed it (using the driver gui thing)
[07:29] <RAOF> You'll need to reboot before the nouveau drivers will kick in.
[07:29] <jman1234> what is default in ubuntu desktop?
[07:29] <RAOF> *Not technically true, but it's generally easier to reboot than to faff around trying to do it without rebooting.
[07:29] <RAOF> Nouveau.
[07:29] <jman1234> ok just finished rebooting
[07:30] <RAOF> Ah, the merry boot speed of someone who isn't testing btrfs :)
[07:31] <RAOF> Any joy?
[07:31] <jman1234> vga monitor is fine
[07:31] <jman1234> system>preferences>monitors doesnt have any mention of the 2nd monitor
[07:32] <jman1234> this is the same behaviour i was getting back in 10.04 and in 10.10 before i installed nvidia drivers
[07:32] <RAOF> I bet dmesg will have something about a missing EDID.
[07:33] <jman1234> paste.ubuntu.com/532186 <-xorg.0.log
[07:34] <RAOF> dmesg is going to be more interesting; Running “dmesg | pastebinit -” should send that to a pastebin.
[07:34] <jman1234> lol pastebininit
[07:36] <jman1234> if i grep EDID i get a lot of *ERROR*'s
[07:36] <jman1234> for DVI-I-1
[07:36] <RAOF> Yeah.  It's going to be looking at the EDID, finding it's corrupt, and going “OMG! A WALRUS!”
[07:37] <jman1234> EDID checksum invalid etc
[07:37] <RAOF> I'm not quite sure why it decides that means it should mark DVI-I-1 as *disconnected*, though; that seems a bug.
[07:38] <jman1234> there should be an option to force modes onto displays
[07:38] <jman1234> like via GUI
[07:38] <RAOF> Yeah; that's something I'll be working on.
[07:38] <RAOF> It's possible with xrandr at the moment, but it should be exposed in a GUI.  With suitable admonishments about blowing up ancient monitors.\
[07:39] <jman1234> it seems nouveau just decides the monitor isnt even worth an attempt to display something on
[07:40] <jman1234> ah yes xrandr
[07:40] <RAOF> Yeah.  That should be regarded as a bug.
[07:40] <jman1234> i should try that again
[07:41] <jman1234> xrandr fails
[07:41] <JanC> RAOF: maybe some newer screens can blow up too (maybe not consumer stuff, but I'm not sure all embeded stuff has proper protection against misconfiguration?)
[07:42] <jman1234> they definately do now
[07:42] <RAOF> JanC: Oh, it's possible to physically damage LCD displays, but the drivers don't expose those knobs.
[07:42] <jman1234> i know some old CRT's could do crazy stuff if set at too high refresh rates
[07:43] <jman1234> now lcds will usually show out of range or something
[07:43] <jman1234> here is my attempt at xrandr http://paste.ubuntu.com/532190
[07:44] <JanC> jman1234: you could actually make the electronics in many ancient CRT monitors to *explode* too ;)
[07:44]  * RAOF would love to see that.  From a safe distance :)\
[07:45] <jman1234> lol. probably a pop would be heard as the components release their magic smoke
[07:45] <JanC> hehe, until now I only had a power supply say *pop* and give a burning smell and a bit of smoke  ;)
[07:46] <RAOF> Dinner time here; sorry this hasn't been more helpful.
[07:46] <jman1234> I've had IC's split in half, capacitors ping off boards ricocheting off walls :P
[07:47] <jman1234> alright thanks RAOF
[07:47] <jman1234> yeah xrandr gave some error when i tried to set the dvi screen to a modeline
[07:48] <jman1234> "Configure crtc 1 failed"
[07:49] <jman1234> RAOF are you in australia by any chance?
[07:51] <jman1234> internode. indeed he is
[08:02] <jman1234> is nouveau configurable with xorg.conf? any examples to force modelines?
[08:04] <RAOF> http://wiki.debian.org/XStrikeForce/HowToRandR12
[08:05] <jman1234> my current xorg.conf is empty
[08:06] <jman1234> what should go in driver under the device section?
[08:07] <jman1234> also any idea why xrandr was unable to get the dvi display going? http://paste.ubuntu.com/532190
[11:02] <JanC> jman1234: I guess the driver thinks no monitor is connected...
[11:02] <JanC> maybe because it didn't manage to get a proper EDID
[11:03] <JanC> I would check the DVI cable (maybe try another one?)
[11:05] <JanC> also, with the open source drivers, xorg.conf should ideally be empty or not exist even, in your case maybe it should contain a monitor section...
[12:02] <jman1234> JanC: windows drivers are able to collect correct EDID's so i dont think the cable or monitor is the problem. is there some command to generate a xorg.conf? what should i put as the driver in the device section when using the nouveau drivers.
[12:02] <JanC> you should not need anything in the Device Section...
[12:14] <jman1234> ok well i have tried writing an xorg.conf and so far it hasnt made any difference
[18:25] <stephank> I'm writing some WebGL stuff, but I'm seeing incorrect output for some very basic shaders. Now I'm looking at launchpad and (in my case) intel's bugtracker on freedesktop, and lots of bugs seem really broad in subject. I'm not even sure how to figure out if my bug is already known?
[18:32] <stephank> Hope I'm not being awfully vague. Maybe I should just report the issue, and attach my test case, seeing as I can't seem to find anything related.
[19:53] <JanC> stephank: I think the developers prefer clear bugs with testcases over those broad fuzzy ones, so yours would be more likely to get fixed  ;)
[20:01] <Sarvatt> stephank: http://intellinuxgraphics.org/how_to_report_bug.html would be the most appropriate, you want to file it on freedesktop.org against the mesa product with the appropriate dri driver component that you are seeing the failure on. fwiw your webgl test case shows light pink here on the nvidia blob
[20:03] <Sarvatt> for firefox you can install libosmesa6 and change the webgl.osmesalib option in about:config to the right path to libosmesa to test software rendering
[20:24] <stephank> Sarvatt: Totally weird thing is, I get the same result using software rendering. (Pretty sure it's doing sw rendering. I enabled verbose and it tells me in the console.)
[20:27] <Sarvatt> stephank: just curious, what mesa version?
[20:28] <stephank> Sarvatt: I'm on maverick, the package version of libgl1-mesa-dri is 7.9~git20100924-0ubuntu2
[21:01] <doctormo> In the new xorg input system, how does the system know an input is available?
[21:02] <doctormo> I'm trying to think of the quickest way to enable serial wacom tablets which usually have a /dev/ttyS0 node.
[21:02] <doctormo> The file xorg.conf.d/50-wacom.conf mentions something about serial wacom, but then doesn't specify the device to use.
[21:03] <doctormo> As if it's disconnected somehow from detection.
[21:10] <jcristau> X gets told by udev when a device appears
[21:17] <doctormo> jcristau: So is there a way to tell udev there is a certain kind of device connected to a serial port?
[21:18] <jcristau> well you can tell that to X
[21:19] <jcristau> like Section "InputClass" Identifier "my serial device" MatchDevicePath "/dev/ttyS0" Driver "wacom" EndSection
[21:19] <jcristau> in your xorg.conf
[21:19] <jcristau> with whatever options are needed
[21:20] <doctormo> jcristau: I'm unhappy about that kind of method. It's hackish.
[21:20] <doctormo> I'd be happier with a udev solution, if possible.
[21:21] <jcristau> dunno.  it's serial stuff.  it's always going to be hackish.
[21:22] <tjaalton> serial wacoms should already work
[21:22] <tjaalton> since lucid
[21:23] <tjaalton> though only builtin models I guess
[21:27] <doctormo> tjaalton: Do you know how they work?
[21:28] <tjaalton> doctormo: I have a lenovo X61 which has one
[21:28] <tjaalton> and it works
[21:28] <doctormo> tjaalton: Did you have to do anything? and is it really serial or is it usb?
[21:28] <tjaalton> doctormo: works OOTB
[21:29] <tjaalton> and it's serial alright
[21:29] <doctormo> Damn magic... hmm.
[21:30] <tjaalton> the serial device is probed somehow when the system starts
[21:30] <tjaalton> so udev knows about it
[21:31] <doctormo> Ah I think I see where that is happening.
[21:41] <doctormo> tjaalton: Could I get your help please? I'm after pnp information for your tablet.
[21:42] <tjaalton> doctormo: it's not really mine and not at hand atm (a testbed at work)
[21:42] <doctormo> Curses! :-)
[21:42] <doctormo> I'm trying to find a good guide to getting pnp info too.
[21:44] <ion> I have a tablet if that’s relevant.
[21:44] <doctormo> ion: Is it serial or usb?
[21:44] <ion> USB
[21:59] <RAOF> Boo.  No-one told stephank about piglit?
[22:21] <bryceh> who's stephank?
[22:23] <RAOF> He was asking about one of his WebGL shaders that's rendering incorrectly.
[22:23] <RAOF> If he's got a nice test-case, piglit is where it should go!
[22:27] <bryceh> just had one of my systems overheat due to a failed fan on a radeon card
[22:27] <bryceh> I'd just rebooted it but for whatever reason the gpu fan wasn't spinning
[22:28] <bryceh> I'd noticed a smell like someone ironing clothes
[22:28] <bryceh> new graphics card time!
[22:29] <RAOF> Mmmm.
[22:29] <RAOF> The smell of ironing clothes is surprisingly pleasant.
[22:29] <bryceh> indeed
[22:29] <RAOF> Maybe you should keep that card in there, as an air freshener!
[22:29] <bryceh> I'm ok with wrinkles
[22:30] <bryceh> sad... was a nice RV630 dual head card that now supports 3d and kms and everything just right
[22:32] <RAOF> You can probably get about the same performance out of a nice, cheap evergreen card now.
[22:33] <RAOF> As long as you don't mind xorg-edgers, and don't want to alt-tab in compiz :)
[22:33] <bryceh> I had a spare rv505 single-head card which is enough
[22:34] <bryceh> fanless ;-)
[22:34] <bryceh> the machine in question is only used for doing charts and web page generation now so don't need 3d or dual head
[22:34] <RAOF> Yeah.  I got a nice $30 fanless r700 a while back.
[22:35] <bryceh> for whatever reason the case on this one tends to collect a lot of dust
[22:35] <bryceh> and the cat likes to sit on it
[22:35] <RAOF> I suspect these two phenomena might be related :)
[22:35] <bryceh> you may be right
[22:36] <bryceh> you know it makes me wonder how many "X bugs" really are over-heating / under-power issues
[22:37] <RAOF> As a proportion of the user-base, I think few people will hit those sorts of problems.
[22:37] <RAOF> As a proportion of the *bug* set… wouldn't it be nice if we could figure out how the user-base is represented in the bug set? :)