| * bryce waves | 03:46 | |
| wgrant | Good afternoon, bryce. | 03:55 |
|---|---|---|
| superm1 | wgrant, being that you wrote a bunch of patches to gsd, how responsive is upstream usually about reviewing them? | 03:55 |
| superm1 | hi bryce | 03:55 |
| wgrant | superm1: I've only taken a couple upstream; I got a response within 24 hours, and normally committed just a few hours after I submitted a good patch. | 03:56 |
| wgrant | So they're very good. | 03:56 |
| superm1 | bryce, i've got an issue you'll probably get pulled into after we get a valid root cause. | 03:56 |
| superm1 | wgrant, hmk, i submitted something upstream and they immediately said yuck on formatting, resubmit and we'll relook | 03:57 |
| superm1 | gsd's formatting is really a mess. i stuck to a standard with all the source files i touched, but it's not standard among all of the files | 03:57 |
| wgrant | The standard varies within files. | 03:57 |
| superm1 | i think i've gotten too used to working with python code | 03:58 |
| wgrant | One of the files I worked on has 2 spaces in some functions, 8 spaces in others, tabs in others. | 03:58 |
| wgrant | Same. | 03:58 |
| superm1 | and how nice formatting is consistent everywhere | 03:58 |
| wgrant | You do occasionally see tabs in Python. | 03:58 |
| superm1 | when i do though, if it's in a project that i work on regularly, i start throwing knives at people for that :) | 03:58 |
| wgrant | Yep. | 03:59 |
| wgrant | The only place I've seen it recently was in PlayOnLinux. | 03:59 |
| * wgrant shudders. | 03:59 | |
| superm1 | if you're curious, the patch i wrote is to fix the issue i was discussing with jcristau the other day where XF86Eject doesn't work | 04:00 |
| wgrant | If you want evidence that you can make unthinkably horrible code in Python, PlayOnLinux is a good example. | 04:00 |
| wgrant | Ah. | 04:00 |
| wgrant | How're you planning to fix that? | 04:00 |
| wgrant | (I followed the discussion) | 04:00 |
| superm1 | let me show you the patch, sec | 04:00 |
| superm1 | http://bugzilla.gnome.org/show_bug.cgi?id=561275 | 04:00 |
| ubottu | Gnome bug 561275 in plugins "shortcuts don't work if keysym bound to multiple keycodes" [Normal,New] | 04:00 |
| superm1 | it affected way more of my hardware than i wanted it to, so i got antsy waiting for anyone else to write a patch | 04:01 |
| wgrant | Aha. | 04:02 |
| bryce | superm1: oh? | 04:34 |
| superm1 | bryce, yeah bug 297245. it is seeming like a new vendor was introduced for the 1535 | 04:39 |
| ubottu | Launchpad bug 297245 in xorg "Dell Studio 15 Doesn't Boot, White Screen of Death" [Undecided,Confirmed] https://launchpad.net/bugs/297245 | 04:39 |
| superm1 | we dont have a root cause of the white screen yet, but i'm thinking it's not reading the EDID correctly | 04:39 |
| superm1 | unfortunately i've yet to get ahold of any hardware that will reproduce it | 04:40 |
| bryce | superm1: oh, it's using -vesa | 04:43 |
| superm1 | bryce, it only "works" with VESA | 04:43 |
| superm1 | with -intel the white screen is occurring | 04:43 |
| bryce | hmm, comment #7 said that was the log from after reproducing the issue | 04:44 |
| superm1 | from what i gather, there are at least 3 different LCD vendors available, 2 types of LCD, and 2 sets of resolution | 04:44 |
| superm1 | people have been manually setting vesa to get to X at least | 04:45 |
| bryce | mm, yeah, we'd need to see the edid's, to see if it's just bad edid from the monitor | 04:46 |
| bryce | and definitely need an Xorg.0.log[.old] from after booting and seeing the problem, so we can see if the xserver just got confused, or what | 04:47 |
| superm1 | do you have some useful commands that people can post? I can provide good EDIDs from the models of LCD that i know work | 04:47 |
| bryce | I usually ask for 'get-edid | parse-edid' and 'xrandr --verbose' | 04:47 |
| superm1 | does get-edid work outside X? | 04:48 |
| bryce | I believe so | 04:48 |
| bryce | as long as the monitor's connected | 04:48 |
| bryce | it's doing a low level bios call, not X calls | 04:48 |
| superm1 | ah okay yeah that would be a good recommendation then | 04:48 |
| bryce | xrandr might work only when booted into -vesa or whatever | 04:48 |
| superm1 | if it turns out this LCD vendor does have a borked EDID, what are the options though? | 04:48 |
| bryce | but the --verbose flag includes a dump of the EDID | 04:49 |
| superm1 | in terms of fixing it | 04:49 |
| bryce | and the xrandr's parsed EDID is very close to what the X server is using | 04:49 |
| bryce | quirks :-) | 04:49 |
| bryce | unless the edid is completely invalid, in which case shipping a static xorg.conf really is the only option | 04:49 |
| superm1 | yippee. well at least such things will be possible hopefully | 04:50 |
| bryce | although we could upstream the issue and see if the xserver guys can figure out something better | 04:50 |
| bryce | if we at least get the LCD vendor name/model from the EDID, the remainder can be quirked | 04:50 |
| bryce | if nothing can be gotten from the LCD, then the LCD vendor is very very naughty | 04:51 |
| superm1 | which wouldn't be a surprise, they may have been a cost reduction option | 04:51 |
| superm1 | in which case, this is something i'll have to check if the 1535's successor has this LCD vendor as an option | 04:52 |
| bryce | heh, profit reduction option maybe too ;-) | 04:52 |
| bryce | but actually, bad edid is only one possibility. Could be a GPU lockup or some other issue. Can't say for sure without having the Xorg.0.log | 04:53 |
| superm1 | do you have a canned reply that you can drop in as a response asking for edid information and what not? | 04:53 |
| bryce | superm1: also you may want to test against current xserver git. They've put in some reworkings of EDID handling based on some bugs I was seeing, which makes it try harder in certain cases. | 04:53 |
| bryce | I don't think this is one of those cases, but it's well worth a try | 04:54 |
| superm1 | well first things first, i need some hardware that reproduces it :) | 04:54 |
| bryce | yep | 04:54 |
| bryce | nah, I don't have a canned reply for edid. I probably should make a stock one though | 04:54 |
| superm1 | okay i'll write up something tomorrow morning then | 04:54 |
| bryce | cool. Oh, btw this week I'm working on a Dell bug for you guys, that's turning into quite a time sync | 04:55 |
| superm1 | for a belmont related item? | 04:56 |
| superm1 | or for ideastorm related | 04:56 |
| bryce | I may need to ping you for advice on it tomorrow. we had a call this evening (we're trying to get the bug upstreamed to intel). | 04:56 |
| bryce | belmont | 04:56 |
| superm1 | okay yeah pm me or email me tomorrow if you need some further advice on it. | 04:57 |
| bryce | great | 04:57 |
| superm1 | there are so many bugs in belmont, i'm not keeping up with them anymore :) | 04:57 |
| * bryce paints a picture of superm1 swimming in bugs | 05:00 | |
| bryce | night everyone | 05:01 |
| superm1 | night | 05:01 |
| tjaalton | seb128: does xvfb still need to Depend on xauth, xfonts-base, isn't Recommends enough now? | 11:19 |
| seb128 | tjaalton: recommends is likely good enough indeed | 11:21 |
| tjaalton | seb128: ok, moving back to Recommends, thanks | 11:33 |
| seb128 | tjaalton: you're welcome | 11:33 |
| tjaalton | oh nice, so jaunty has a broken libxi without properties | 11:51 |
| tjaalton | and XInput.h, because it got autosynced :P | 11:51 |
| tjaalton | well, I'll add the changes back | 11:54 |
| bryce | tjaalton: yes, riddell mentioned that | 12:50 |
| tjaalton | bryce: yeah, it was the -2build1 upload :) | 12:50 |
| tjaalton | which meant that it would be autosynced when a new version was ready | 12:51 |
| bryce | ah | 12:51 |
| bryce | superm1: bug 297245 is upstream and assigned to jbarnes, although he's not yet commented on it. I'll ping him. | 16:46 |
| ubottu | Launchpad bug 297245 in xserver-xorg-video-intel "[i965] Dell Studio 15 White Screen on X startup" [High,Confirmed] https://launchpad.net/bugs/297245 | 16:46 |
| superm1 | bryce, ah that's great. | 16:49 |
| superm1 | bryce, well the bad news here, if this does end up being attributed to the intel driver's handling of this LCD, the studio 1535's successor does indeed offer this exact same LCD, so the breakage will continue on it | 16:56 |
| bryce | superm1: do you have the hardware on hand to reproduce this issue yourself? | 16:58 |
| superm1 | bryce, i've got several 1535's but not with that LCD manufacturer. I've been trying to track one down with it, but now that i know the 1535's successor has it too, i might have a little more luck finding one | 17:01 |
| bryce | superm1: okay. I've dinged jesse to hopefully bring his attention to it. He's not on IRC so I emailed him. (Possibly he's AFK?) | 17:05 |
| bryce | I didn't see anything wrong with the edid we collected, but given that it occurred after the LCD manufacturer was changed, it does sound like EDID is the thing to look at | 17:06 |
| superm1 | i'll let you know if/when i can finally get ahold of hardware with this | 17:06 |
| bryce | superm1: great. xrandr --verbose would be nice to see. | 17:06 |
| superm1 | we're trying to nab one of the returned models that was returned for this white screen problem (which proves to be more difficult than you anticipate with this big of a company :)) | 17:07 |
| superm1 | bryce, someone from that bug should hopefully be able to get you xrandr --verbose in the meanwhile I think. the reporter on it (Chris Menning) seems to be on top of responding to anything asked for | 17:10 |
| tseliot | bryce: today I received the tablet :-) | 17:16 |
| tseliot | thanks a lot | 17:16 |
| bryce | tseliot: ahh excellent! Finally, I was starting to worry. | 17:47 |
| tseliot | BTW I'll write the wiki pages about the projects ASAP | 17:53 |
| bryce | tseliot: excellent | 18:07 |
| bryce | tjaalton: lool ran into that issue with xorg not starting up due to missing hal - http://pastebin.com/f750ebfb7 | 18:08 |
| bryce | # | 18:08 |
| bryce | (EE) config/hal: couldn't initialise context: (null) ((null)) | 18:08 |
| jcristau | xorg starts up just fine when hal is missing, just with no input devices | 18:09 |
| bryce | okay... ;-) | 18:09 |
| bryce | jcristau: do we need a hal dependency added here somewhere? | 18:11 |
| * bryce summons lool | 18:11 | |
| jcristau | some X package should depend on (or recommend) hal, yeah. and the init scripts for the display managers should depend on hal being started. | 18:12 |
| lool | Hi folks | 18:12 |
| lool | jcristau: So when one installs gdm it pulls xorg and input-all and everything, but fails to start | 18:12 |
| lool | jcristau: I think at some level we need to pull hal | 18:12 |
| jcristau | yup | 18:13 |
| bryce | lool, <jcristau> some X package should depend on (or recommend) hal, yeah. and the init scripts for the display managers should depend on hal being started. | 18:13 |
| lool | jcristau: Currently, in Debian and Ubuntu it will be pulled "externally" by /some/ metapackage | 18:13 |
| lool | jcristau: Ok, good points | 18:13 |
| jcristau | xserver-xorg should be a good candidate for the hal Depends or Recommends. | 18:13 |
| lool | gdm.init looks like crap right now hmm | 18:14 |
| lool | I guess only the real server needs hal, not others like Xvfb right? | 18:14 |
| bryce | lool, do you want to add to gdm? | 18:14 |
| lool | bryce: I'm not sure it's correct | 18:14 |
| lool | I don't think gdm has any knowledge of hal | 18:15 |
| jcristau | i don't think any server other than Xorg implements NewInputDeviceRequest | 18:15 |
| lool | jcristau: Is this NewInputDeviceRequest in an input specific path, like e.g. evdev? | 18:15 |
| lool | If that's the case we could add the dep on xserver-xorg-input-evdev instead | 18:16 |
| jcristau | lool: NewInputDeviceRequest is the DDX function that's called when hal tells the server about an input device | 18:17 |
| * lool doesn't know what ddx is | 18:17 | |
| jcristau | lool: each subdir of hw/ in the xorg-server tree | 18:18 |
| lool | jcristau: I guess my question is rather, is the hal dependency specific to some input module which might not be on the xorg server, or is it really the binary requiring hal? | 18:18 |
| bryce | jcristau: xserver-xorg looks like a good place to hang the dependency. We already have -evdev listed there | 18:18 |
| jcristau | it's Xorg requiring hal to tell it what input devices are there | 18:18 |
| lool | I guess it's in the xorg-server source tree... then we should probably add the dep on the xorg-server indeed | 18:18 |
| jcristau | bryce: 19:13 < jcristau> xserver-xorg should be a good candidate for the hal Depends or Recommends. | 18:19 |
| jcristau | bryce: looks like violent agreement :) | 18:19 |
| lool | I don't mind a recommends, if the server can work with other input devices than the hal provided ones | 18:19 |
| bryce | jcristau: yes I'm agreeing with you ;-) | 18:19 |
| jcristau | lool: it can, but not with the default config | 18:19 |
| lool | People, I strongly agree with you too but we need to flame on smth | 18:19 |
| bryce | ok, I'll put the change in | 18:19 |
| lool | jcristau: Can it with autodetection of the config? | 18:19 |
| lool | I mean, without any xorg.conf? | 18:20 |
| lool | (My use case was no xorg.conf) | 18:20 |
| jcristau | without any xorg.conf, you don't get input devices if you don't have hal, i think | 18:20 |
| lool | hmm | 18:21 |
| jcristau | i guess whether it should be Depends or Recommends kinda depends whether apt will pull it in on upgrade if it's just Recommended | 18:22 |
| lool | It does | 18:22 |
| lool | Unless configured not to -- not our problem | 18:22 |
| jcristau | ok | 18:23 |
| jcristau | then both work. i don't have a strong preference | 18:23 |
| lool | jcristau: Ah stop | 18:23 |
| lool | jcristau: vorlon tells me that apt doesn't do that | 18:23 |
| lool | I'm very confident that aptitude does, but it seems that's an aptitude extension | 18:24 |
| lool | So Depends then? | 18:24 |
| jcristau | i guess so | 18:24 |
| jcristau | and 'Should-Start: hal' in gdm.init, or some such? | 18:25 |
| lool | Yeah | 18:26 |
| lool | jcristau: Hmm it has it already | 18:28 |
| lool | Probably not in Ubuntu though | 18:29 |
| jcristau | oh. good. | 18:29 |
| jcristau | i only have xdm installed here... | 18:30 |
| lool | bryce: http://launchpadlibrarian.net/19793798/buildlog_ubuntu-jaunty-powerpc.libgtk2-perl_1%3A1.190-1ubuntu1_FAILEDTOBUILD.txt.gz | 18:32 |
| bryce | powerpc :-o | 18:32 |
| lool | chroot needs cleanup | 18:32 |
| jcristau | /tmp/.X99-lock left around, i guess? | 18:33 |
| lool | Actually was still running from previous build | 18:41 |
| lool | And using all CPU | 18:41 |
| lool | I think I ran into this once with missing bdeps, but don't recall how to reproduce | 18:42 |
| lool | Anyway, buildd admin fixed it for now | 18:42 |
| lool | If someone reproduces he should fix xvfb-run to not use 100% CPU but die | 18:42 |
| lool | When the package is removed | 18:42 |
| lool | jcristau, bryce: I added a depends on hal in Debian's gdm because of the should-start | 18:43 |
| lool | (in SVN) | 18:43 |
| lool | thanks all | 18:43 |
| jcristau | should-start means 'start if available', it's not a dependency.. | 18:43 |
| bryce | lool, great :-) | 18:44 |
| lool | jcristau: I think it should be one, shouldn't it? | 18:44 |
| jcristau | is the depends in xserver-xorg not enough? | 18:44 |
| bryce | and the xserver-xorg change is committed to git and uploaded to jaunty now. | 18:44 |
| jcristau | lool: not if gdm itself doesn't use hal, no | 18:44 |
| lool | Hmm | 18:44 |
| lool | We are listing hal here because we're leaking into gdm the fact that xorg server needs hal to work | 18:46 |
| lool | We need to leak it because we care about representing that in init scripts and xorg server doesn't have an init script | 18:46 |
| lool | If we leak that in the init script, we might as well be consistent and leak it in the deps | 18:46 |
| jcristau | yeah. but depending how it's configured, gdm might not even start an X server. | 18:46 |
| lool | True, so let's make it a recommends | 18:46 |
| jcristau | why? xserver-xorg will already have the Depends... | 18:47 |
| lool | We should have a gdm-bin thingy like you have a split between meta and binaries | 18:47 |
| jcristau | the init script says 'hey, i might start Xorg, and if i do it needs hal started' | 18:47 |
| jcristau | but you don't need that leaking in the packaging, since Xorg can have deps of its own :) | 18:48 |
| lool | Yeah, so the package deps might want to say "Hey, I might need xorg (recommends) and my init script will attempt to start hal because it's needed in most cases (recommends)"? | 18:49 |
| lool | But I've reverted it | 18:49 |
| lool | I don't have a strong opinion on it, and I know we have too many deps | 18:49 |
| lool | Can't think of something that would break without the dep, so I don't need to care too much | 18:49 |
| lool | jcristau: thanks for discussion | 18:49 |
| tjaalton | bryce: the displayconfig-gtk change was added to the old changelog entry :) | 18:57 |
| tjaalton | not hugely important though | 18:59 |
| tjaalton | -gh | 18:59 |
| bryce | ok | 19:09 |
| tjaalton | bryce: fixed it in git | 20:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!