[00:13] <pwnguin> ok, this is crazy
[00:13] <pwnguin> https://bugs.launchpad.net/ubuntu/+source/thinkfinger/+bug/276850
[01:09] <bryce> jcristau: can you reproduce lp #276887 on debian?
[01:19] <jcristau> bryce: i get some 'fun' stuff on vt switch, but it seems to be mostly the alt-f7 release, not other stuff i type on the console
[01:21] <jcristau> xev sees a keyrelease for XF86_Switch_VT_1, then keyrelease for control, alt, and f7
[01:23] <jcristau> hrm.
[01:23] <jcristau> bryce: actually it looks like i can reproduce
[01:23] <bryce> jcristau: ahh
[01:24] <ion_> Huh. On one intrepid box, multiple gdm logins work just fine. On another, only the first one receives input.
[01:26] <jcristau> bryce: probably xserver bug. or maybe evdev driver. talk to whot, i guess?
[01:27] <bryce> jcristau: kees was able to reproduce without evdev
[01:27] <jcristau> ok
[01:29] <jcristau> anyway, 2:30am here, and i need to be more awake than the students tomorrow morning, so, sleep :)
[01:29] <bryce> night
[01:29] <bryce> thanks
[01:29] <jcristau> np
[01:42] <wgrant> bryce: Do you know what a reasonable value for XRandR max brightness is?
[01:42] <wgrant> g-p-m is trusting it a bit too much, I think.
[01:42] <bryce> wgrant: nope
[01:42] <jcristau> wgrant: very machine-dependent
[01:43] <wgrant> I think that gpm_brightness_xrandr_output_set is on crack, then.
[01:44] <wgrant> It seems to loop, incrementing it by one each iteration, presumably to get a gradual change.
[01:44] <wgrant> But that doesn't work so well when it changes it to 15000.
[01:44] <wgrant> (it also sleeps for 5ms each time)
[01:47] <wgrant> I see that on another machine it's 7...
[01:47] <wgrant> Do I complain at X, or do I complain at g-p-m?
[01:49] <wgrant> 15125 doesn't sound like a particularly sane value for XRandR brightness.
[01:51] <wgrant> jcristau: Do you think I should complain at X for giving me a bogus value, or should I complain at g-p-m for trusting it? Can X be expected to give a sane value in circumstances where the hardware doesn't support it?
[01:58] <bryce> wgrant: you should probably raise it to g-p-m
[01:58] <bryce> wgrant: since it sounds like xrandr is simply exposing hardware-provided values
[01:59] <bryce> let me take a quick look at the source though
[02:00] <wgrant> bryce: Dell backlights are controlled through other means.
[02:00] <wgrant> g-p-m will stop if X says that it failed, but X doesn't.
[02:01] <wgrant> Maybe g-p-m should be taught to not use more than 10 increments or something.
[02:01] <bryce> wgrant: I see this is new code in 2.24 that wasn't in 2.22 apparently, so that leads me to think it's incorrect implementation in gnome
[02:02] <wgrant> bryce: Right, I've looked through those bits of code fairly thoroughly.
[02:02] <wgrant> It's probably fine unless X reports ridiculous values.
[02:03] <bryce> ok, so it's using XRRChangeOutputProperty to set the brightness I gather
[02:03] <wgrant> Yes.
[02:04] <wgrant> On my machine we get something like this:
[02:04] <wgrant> TI:11:04:06	TH:0x9777640	FI:gpm-brightness-xrandr.c	FN:gpm_brightness_xrandr_output_set,322 - percent=50, absolute=7563
[02:04] <wgrant> TI:11:04:06	TH:0x9777640	FI:gpm-brightness-xrandr.c	FN:gpm_brightness_xrandr_output_set,324 - hard value=15125, min=0, max=15125
[02:04] <bryce> and XRRQueryOutputProperty to retrieve them
[02:04] <wgrant> Yep.
[02:04] <bryce> so on the xrandr side, those are going to be fairly generic functions
[02:05] <wgrant> And now we get:
[02:05] <wgrant> TI:11:04:49	TH:0x9777640	FI:gpm-brightness-xrandr.c	FN:gpm_brightness_xrandr_output_set,322 - percent=100, absolute=15125
[02:05] <wgrant> TI:11:04:49	TH:0x9777640	FI:gpm-brightness-xrandr.c	FN:gpm_brightness_xrandr_output_set,324 - hard value=7563, min=0, max=15125
[02:05] <wgrant> So we have 7562 iterations.
[02:05] <wgrant> Which is very slow.
[02:05] <bryce> mm
[02:06] <wgrant> And those values look like they come straight from X.
[02:06] <wgrant> (from XRRQueryOutputProperty, at least)
[02:07] <bryce> right, but I think gpm needs to be smarter at how it uses them
[02:07] <bryce> I think the numbers are likely to be valid representations from the underlying hardware (I guess)
[02:07] <wgrant> Right. It should probably limit the number of increments.
[02:07] <wgrant> They don't apply to my hardware.
[02:07] <wgrant> So it should really fail.
[02:07] <wgrant> But it doesn't.
[02:09] <bryce> I wonder if that shared_value_abs calculation is incorrect
[02:10] <wgrant> I don't think so.
[02:10] <wgrant> It's max/2.
[02:10] <wgrant> And max is very large.
[02:12] <bryce> what does this say? 
[02:12] <bryce> $ xrandr --prop | grep -i light
[02:12] <bryce> 	BACKLIGHT_CONTROL: kernel
[02:12] <bryce> 	BACKLIGHT: 7 (0x00000007) range:  (0,7)
[02:12] <wgrant> 	BACKLIGHT_CONTROL: combination
[02:12] <wgrant> 	BACKLIGHT: 15125 (0x00003b15) range:  (0,15125)
[02:12] <wgrant> As expected.
[02:13] <bryce> okay
[02:14] <bryce> wgrant: can you manually poke at it with xrandr --output <output> --set backlight <number>
[02:15] <wgrant> X Error of failed request:  BadName (named color or font does not exist) Major opcode of failed request:  153 (RANDR) Minor opcode of failed request:  11 () Serial number of failed request:  18 Current serial number in output stream:  18
[02:15] <wgrant> So maybe it does fail.
[02:15] <bryce> wgrant: see if that 0,15125 is a smooth range, like if you poke 1000, 2000, ... 15000 does that give reasonable increments
[02:15] <wgrant> bryce: It doesn't do anything - it's a Dell.
[02:15] <wgrant> But if it fails, then g-p-m should break out of the loop. But it doesn't...
[02:16] <bryce> ah, has to be BACKLIGHT, not backlight
[02:16] <bryce> xrandr --output LVDS --set BACKLIGHT 3 dims my display
[02:16] <wgrant> It works.
[02:16] <wgrant> But does precisely nothing.
[02:16] <bryce> $ xrandr --output LVDS --set BACKLIGHT 7 sets it to max
[02:17] <wgrant> That's what I would expect.
[02:17] <bryce> this fails:
[02:17] <bryce> ~$ xrandr --output LVDS --set BACKLIGHT 8
[02:17] <bryce> X Error of failed request:  BadValue (integer parameter out of range for operation)
[02:17] <bryce>   Major opcode of failed request:  153 (RANDR)
[02:17] <bryce>   Minor opcode of failed request:  13 ()
[02:17] <bryce>   Value in failed request:  0x3c
[02:17] <bryce>   Serial number of failed request:  19
[02:17] <wgrant> But Dell does things specially (it's handled by hald-addon-dell-backlight
[02:17] <bryce>   Current serial number in output stream:  20
[02:17] <bryce> hmm, well mine is a dell inspiron 1420n
[02:17] <wgrant> Right, it fails appropriately if I put it out of range.
[02:17] <wgrant> Wait.
[02:17] <wgrant> It just gradually went dark, I think.
[02:17] <wgrant> It did this for a while in hardy.
[02:18] <wgrant> Grrrr.
[02:18] <wgrant> Indeed, it works, but very, very slowly.
[02:18] <bryce> on a different dell with -ati I have backlight range (0,255)
[02:18] <bryce> take it yours is intel graphics?
[02:18] <wgrant> i915, yes.
[02:18] <wgrant> Inspiron 630m.
[02:18] <wgrant> Let's see if it goes dark again...
[02:19] <bryce> interesting, on the ati system I can poke whatever I want into the backlight value but the backlight doesn't change
[02:19] <wgrant> Right, this is similar to the behaviour I was seeing for a while in Hardy, without having to poke anywhere... if I set BACKLIGHT low, over a little under a minute it will get there.
[02:19] <wgrant> If I set it high, it'll get there, but very slowly.
[02:20] <bryce> bleah
[02:20] <bryce> ok, well at least this sort of rules out g-p-m
[02:20] <bryce> wgrant: why not report it to bugs.freedesktop.org against the xserver and see how it goes?
[02:20] <wgrant> I believe I do really have 0->7.
[02:20] <wgrant> That's what the brightness keys used to do, at least.
[02:21] <wgrant> But they seem to largely be in hardware.
[02:21] <wgrant> Although the OSD was right.
[02:21]  * wgrant files it.
[02:21] <bryce> fwiw, I notice in the xrandr manpage for properties that both decimal and hex values can be given
[02:22] <bryce> however I sort of doubt this is a mixup between number systems.  Sounds like it's hardware giving bad data
[02:52] <wgrant> bryce: Hmmm, it seems that g-p-m can't really be blamed for my other bug either.
[02:52] <wgrant> There really are many thousands of brightness key events.
[02:52] <wgrant> But there weren't in Hardy AFAICT.
[02:54] <wgrant> THey just keep coming until I press another key...
[06:45] <tjaalton> morning
[06:46] <wgrant> Morning tjaalton.
[06:46] <tjaalton> Ng: yes, work just fine
[06:46] <tjaalton> hey wgrant
[06:47] <tjaalton> our nurse is sick so I had to stay home.. probably can have a look at the properties stuff again some time today
[06:48] <wgrant> I'd really like to know why it particularly dislikes me.
[06:49] <bryce> heya tjaalton
[06:50] <tjaalton> hey bryce, remember to push the patch to git too ;)
[06:50] <bryce> oh feh
[06:50] <bryce> er, which patch?
[06:50] <tjaalton> evdev
[06:51] <bryce> hm, didn't know evdev was in git
[06:51] <tjaalton> yeah, probably so.. i haven't been too vocal about what packages are
[06:51] <tjaalton> synaptics is too
[06:52] <tjaalton> since we need stuff from master
[06:52] <tjaalton> so it's easier to pull with git
[06:53] <bryce> to be honest having things in git hasn't been that convenient for me
[06:54] <bryce> admittedly it may just be due to me getting confused by git, but...
[06:54] <tjaalton> hmm :)
[06:56] <tjaalton> I probably should update the git docs in wiki
[09:37] <Ng> tjaalton: huh, weird, my x61 owning chum says his aren't working at all
[10:09] <tjaalton> Ng: ask him to try a livecd
[10:09] <Ng> yeah good plan
[10:09] <tjaalton> or a fresh user
[14:06] <Ng> tjaalton: the same guy is also seeing http://gallery.casualgenius.com/corrupt_boot.jpg about 1 in 3 boots :o
[14:09] <tjaalton> oh, still
[14:09] <tjaalton> I don't anymore
[14:10] <Ng> hmm, but you did?
[14:10] <Ng> I think he's using some weird version of usplash. he's a bit of a magpie about downloading random crazy debs
[14:11] <tjaalton> yes, I did, but not anymore with the current kernel
[14:11] <Ng> interesting
[14:12] <Ng> tjaalton: do you happen to know if there was a bug about it?
[14:19] <tjaalton> Ng: I think so, but can't remember which one
[14:19] <Ng> ok