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