| pwnguin | ok, this is crazy | 00:13 |
|---|---|---|
| pwnguin | https://bugs.launchpad.net/ubuntu/+source/thinkfinger/+bug/276850 | 00:13 |
| ubottu | Launchpad bug 276850 in thinkfinger "thinkfinger disabled mouse and keyboard in x" [Undecided,New] | 00:13 |
| bryce | jcristau: can you reproduce lp #276887 on debian? | 01:09 |
| ubottu | Launchpad bug 276887 in xkeyboard-config "Input to TTYs goes to X after returning" [Critical,Confirmed] https://launchpad.net/bugs/276887 | 01:09 |
| 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:19 |
| jcristau | xev sees a keyrelease for XF86_Switch_VT_1, then keyrelease for control, alt, and f7 | 01:21 |
| jcristau | hrm. | 01:23 |
| jcristau | bryce: actually it looks like i can reproduce | 01:23 |
| bryce | jcristau: ahh | 01:23 |
| ion_ | Huh. On one intrepid box, multiple gdm logins work just fine. On another, only the first one receives input. | 01:24 |
| jcristau | bryce: probably xserver bug. or maybe evdev driver. talk to whot, i guess? | 01:26 |
| bryce | jcristau: kees was able to reproduce without evdev | 01:27 |
| jcristau | ok | 01:27 |
| 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:29 |
| 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:42 |
| wgrant | I think that gpm_brightness_xrandr_output_set is on crack, then. | 01:43 |
| 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:44 |
| 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:47 |
| wgrant | 15125 doesn't sound like a particularly sane value for XRandR brightness. | 01:49 |
| 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:51 |
| 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:58 |
| bryce | let me take a quick look at the source though | 01:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| bryce | ok, so it's using XRRChangeOutputProperty to set the brightness I gather | 02:03 |
| wgrant | Yes. | 02:03 |
| wgrant | On my machine we get something like this: | 02:04 |
| wgrant | TI:11:04:06TH:0x9777640FI:gpm-brightness-xrandr.cFN:gpm_brightness_xrandr_output_set,322 - percent=50, absolute=7563 | 02:04 |
| wgrant | TI:11:04:06TH:0x9777640FI:gpm-brightness-xrandr.cFN: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:04 |
| wgrant | And now we get: | 02:05 |
| wgrant | TI:11:04:49TH:0x9777640FI:gpm-brightness-xrandr.cFN:gpm_brightness_xrandr_output_set,322 - percent=100, absolute=15125 | 02:05 |
| wgrant | TI:11:04:49TH:0x9777640FI:gpm-brightness-xrandr.cFN: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:05 |
| wgrant | And those values look like they come straight from X. | 02:06 |
| wgrant | (from XRRQueryOutputProperty, at least) | 02:06 |
| 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:07 |
| bryce | I wonder if that shared_value_abs calculation is incorrect | 02:09 |
| wgrant | I don't think so. | 02:10 |
| wgrant | It's max/2. | 02:10 |
| wgrant | And max is very large. | 02:10 |
| 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:12 |
| bryce | okay | 02:13 |
| bryce | wgrant: can you manually poke at it with xrandr --output <output> --set backlight <number> | 02:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| bryce | however I sort of doubt this is a mixup between number systems. Sounds like it's hardware giving bad data | 02:22 |
| 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:52 |
| wgrant | THey just keep coming until I press another key... | 02:54 |
| tjaalton | morning | 06:45 |
| wgrant | Morning tjaalton. | 06:46 |
| tjaalton | Ng: yes, work just fine | 06:46 |
| tjaalton | hey wgrant | 06:46 |
| 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:47 |
| wgrant | I'd really like to know why it particularly dislikes me. | 06:48 |
| bryce | heya tjaalton | 06:49 |
| 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:50 |
| 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:51 |
| tjaalton | since we need stuff from master | 06:52 |
| tjaalton | so it's easier to pull with git | 06:52 |
| bryce | to be honest having things in git hasn't been that convenient for me | 06:53 |
| bryce | admittedly it may just be due to me getting confused by git, but... | 06:54 |
| tjaalton | hmm :) | 06:54 |
| tjaalton | I probably should update the git docs in wiki | 06:56 |
| Ng | tjaalton: huh, weird, my x61 owning chum says his aren't working at all | 09:37 |
| tjaalton | Ng: ask him to try a livecd | 10:09 |
| Ng | yeah good plan | 10:09 |
| tjaalton | or a fresh user | 10:09 |
| Ng | tjaalton: the same guy is also seeing http://gallery.casualgenius.com/corrupt_boot.jpg about 1 in 3 boots :o | 14:06 |
| tjaalton | oh, still | 14:09 |
| tjaalton | I don't anymore | 14:09 |
| 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:10 |
| tjaalton | yes, I did, but not anymore with the current kernel | 14:11 |
| Ng | interesting | 14:11 |
| Ng | tjaalton: do you happen to know if there was a bug about it? | 14:12 |
| tjaalton | Ng: I think so, but can't remember which one | 14:19 |
| Ng | ok | 14:19 |
| === Ng_ is now known as Ng | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
