tjaaltonbryce: you can upload xorg if you like, I'm going to bed :)00:01
tjaaltonnvidia 173/177 and fglrx-installer need a rebuild too00:02
* bryce uploads xorg. no more displayconfig-gtk01:35
wgrantbryce: How does one choose video drivers now if displayconfig-gtk is gone?06:33
brycewgrant: you don't ;-)07:13
wgrantbryce: How does one choose between nouveau, nv and nvidia?07:20
brycenouveau is still pre-release07:20
brycenvidia can be chosen via jockey07:20
brycethe xorg-options-editor blueprint tseliot's working on will also have a general purpose GUI driver selector07:21
brycethat's not scheduled for upload until jaunty, however he has got most of the code written07:22
bryceI don't think displayconfig-gtk allowed selecting nouveau either, and while it let you pick nvidia, I don't think it got things set up correctly as reliably as jockey does07:23
wgrantxorg.conf is basically going to become a file to select the video driver, isn't it?07:23
wgrantIt doesn't seem to be needed for much except that and Virtual now.07:24
bryceactually no; ultimately it will be completely vestigial07:24
wgrantHow would one select the video driver?07:25
brycethere's code going in to do auto-fallback of drivers, so specifying the driver should only be needed if you're experimenting 07:25
brycethe idea is, if you have nvidia installed, it should of course use that first07:25
bryceif it crashes or otherwise can't be loaded, then xserver should automatically go to nv (or nouvaeu if/when it's released), then vesa, etc.07:26
brycexorg.conf may be necessary if you wish to override default device options07:26
brycehowever long term I think even that is going to go away, with plans to make option setting on the fly possible07:27
tjaaltonmorning folks07:30
tjaaltoneventually there'll be output properties just like there are input properties now07:32
tjaaltonwas it randr-1.3 stuff, I'm not sure07:32
tjaaltonbtw, the fallback stuff doesn't work right, at lest for the guy who has an nvidia card which nv doesn't support. the driver fails to use it, but falling back to vesa fails as well07:33
tjaaltonmight be a bug in nv though07:34
tjaaltonI mean, not releasing the device07:34
wgrantMorning tjaalton.07:34
tjaaltonwgrant: hey, how's the new synaptics working?-)07:34
wgranttjaalton: I hear that vertical scrolling is fixed in at least some of the broken devices now.07:34
brycetjaalton: aha, yeah I expected it'd take a bit more work07:35
wgrantan upgrade uninstalled nautilus for me. Nice of it.07:35
tjaaltonbryce: yeah, vesa fails with (EE) No devices07:35
tjaaltonbryce: I've sent an email to alanc who implemented that, but haven't heard from him07:36
tjaaltonI'm hopefully getting a new mb for the laptop today.. tough living without ethernet07:37
tjaaltonand all my git stuff is in there07:38
wgrantEthernet chips don't often die... were you a victim of the firmware overwriting bug?07:38
tjaalton(vista upgrade broke the device, it failed with "NVM checksum error", and IBAUTIL.EXE finished the job)07:38
tjaalton^^ :)07:38
tjaaltonI had to boot to vista because I wanted to clear the airbag error on my car, but couldn't find the cable. so, vista decided to install upgrades which took ~1h07:39
tjaaltonafter that, no ethernet07:40
tjaaltonwho needs it anyway07:40
tjaaltonI should try VAG-COM with wine, might work now07:40
wgrantWhat does Vista have to do with your car, and why?07:41
tjaaltonit has the software07:41
wgrantYour car has a USB port?07:42
wgrantThat is mildly scary.07:42
tjaaltonno, OBD07:42
tjaaltonbut I have a rs232-OBD cable07:42
tjaaltonhum sorry, that's not what it's called07:42
wgrantAh. Laptop with RS232. Haven't seen one of them in a while!07:42
tjaaltonrigh, it was OBD-II07:43
tjaaltonneither does my X61 have one, but the dock does :)07:43
tjaaltondon't know if an usb-serial dongle might work with it07:44
tjaaltonI'll upload a new mesa with the vblank commit reverted07:53
tjaaltonthat will do until upstream knows the real fix07:54
brycetjaalton: arghlgle...  as if you needed more reasons to dislike vista07:54
brycetjaalton: btw I got some oddball build errors on my -intel upload today07:55
tjaaltonbryce: yeah.. if only the hw vendors would get their act together and support linux.. logitech and nokia are to blame too..07:55
tjaaltonbryce: but on archs we don't care about?07:55
brycelike hppa, ppc, etc07:55
brycethe error messages were in packaging/changelog stuff, not actually compile errors07:56
bryceok good, I thought maybe it was an expected error07:56
brycethe other driver builds and xorg went through fine07:57
tjaaltonwell, I think the problem is that -i810 is an arch: all package07:59
tjaaltonso that's why -intel is built on those archs07:59
tjaaltonwhile it should not be07:59
tjaaltondh_installdeb: I have no package to build07:59
tjaaltonso no problem there08:00
tjaalton-i810 will be dropped after lenny I guess08:00
brycetomorrow I'm going to meet up with slangasek downtown so hopefully can look into that keyboard issue on that08:00
tjaaltonI think there are two things mixed up here08:00
tjaaltonone is the acpi keys and the other is the media stuff08:00
bryceof course, if you end up solving it between now and then, I definitely wouldn't be unhappy!  :-)08:00
* bryce nods08:01
tjaaltongnome key shortcuts probably are still listening some hexcodes, not the 'XF86FOO' that evdev produces08:01
bryceyeah I definitely know the sleep-key-no-work issue I see is completely different from mdz's08:01
tjaaltonseb128 said that the patch to g-s-d (or g-c-c, can't remember) should be dropped already08:02
tjaaltonbtw, whot made a new blog post about the xkb stuff08:02
tjaalton(and happened to credit me, too :)08:02
bryceoh cool08:04
tjaaltonthat helps a bit in understanding some of this08:05
brycewhot == peter hutterer?08:08
tjaaltonuh, so the drirc workaround for the intel hang doesn't seem to work for all, so there are different bugs involved09:35
tjaaltonanyway, mesa uploaded09:35
wgranttjaalton: Hm, it worked for me.09:45
tjaaltonwgrant: that's good, I left the bug open to make sure it's not forgotten09:45
wgranttjaalton: Why did you ask about the two-fingered scrolling a couple of days back?09:46
wgrant(the lack of UI for it, in particular)09:46
tjaaltonsomeone asked for it09:46
wgrantI hope to give us a complete Synaptics GUI for Jaunty. As long as nobody else has it planned.09:47
tjaaltonnice, remember to work with gnome upstream ;)09:47
wgrantI guess this can go upstream now it doesn't depend on that hack.09:48
* wgrant stabs GTK.09:58
wgrantStupid flickering.09:58
seb128wgrant: stab xorg rather09:59
wgrantseb128: So what is actually causing it?10:02
seb128wgrant: xorg10:02
seb128let me find you the bug number10:02
tjaaltonseb128: well, gtk probing those fills Xorg.0.log..10:03
tjaaltonthose = outputs10:03
tjaaltonit shouldn't do that10:03
ubottuGnome bug 544072 in general "GTK+ calls XRRGetScreenResources() altogether far too frequently" [Major,Unconfirmed] 10:03
wgrantIs that why I'm getting hundreds of lines of -intel EDID stuff in logs?10:03
seb128XRRGetScreenResources() is doing this flickering10:03
seb128and there is a disagrement upstream on whether gtk should not call it or if should not be as expensive10:04
seb128I think they are leading to "add a new api less expensive that gtk could use for what is needed"10:04
wgrantGTK lived fine without it until not long ago...10:05
seb128wgrant: GTK was not xrandr aware until not long ago10:16
wgrantseb128: Why does my UI toolkit need to be XRandR-aware?10:30
seb128wgrant: to handle screen changes correctly10:30
wgrantI see.10:30
seb128wgrant: read https://bugs.freedesktop.org/show_bug.cgi?id=1622410:31
ubottuFreedesktop bug 16224 in Driver/intel "Opening new window causes external monitor to momentarily blank" [Normal,Resolved: notourbug] 10:31
wgrantseb128: Right, I saw that earlier.10:32
seb128I think there was some details about what GTK need there, maybe that's on the list discussion10:32
seb128but it needs details about the available screens, the geometry etc to optimize screen usage10:32
jcristauseb128: until the lightweight api exists, gtk should revert to just getting the geometry from xinerama...10:36
seb128jcristau: maybe, I'm not GTK upstream though and I don't want to do that in a distro specific way10:41
jcristauthat doesn't make any sense to me10:42
seb128jcristau: why?10:50
jcristaulast i checked the only thing gdk used from randr was the geometry, which it can get from xinerama, without the nasty side-effects10:57
jcristaubut even then, the side-effects of XRRGetScreenResources are enough of a reason to not use it every time you start an app10:58
seb128jcristau: http://bugzilla.gnome.org/show_bug.cgi?id=43958810:59
ubottuGnome bug 439588 in gdk "Use XRANDR 1.2 instead of Xinerama when available" [Enhancement,Resolved: fixed] 10:59
jcristauhrm. sucks.11:00
jcristauddc is slow, so in addition to flicker you get a one second xserver hang..11:02
=== mvo__ is now known as mvo
=== mvo__ is now known as mvo
tjaaltonbryce: I'll be at the meeting, need to get home first ->15:26
Solarioncrevette: bonjour!15:46
Solarionanyone have an idea why the screen blanking (for screensaver) would cause the system to lock up?15:47
NgSolarion: it's a known bug, tjaalton has tracked it down to something in Mesa15:52
NgSolarion: see https://bugs.launchpad.net/bugs/26260515:52
ubottuLaunchpad bug 262605 in mesa "[intrepid] X locks up or crashes when screensaver activates" [High,Confirmed] 15:52
crevettesalut Solarion15:55
Solarionin other news, metal drawer handles frickin' *hurt* when you whang into them with your knee at high speeds15:56
Solarionrolley-chair + old-style desk = pain15:57
SolarionNg: thanks,, btw15:57
Solarionany idea when the new mesa will hit?15:59
NgSolarion: nope16:06
tjaaltonSolarion: uploaded already, at least archive.ubuntu.com has it16:07
Solariontjaalton: when was that?16:12
Solarionwhat version would that be?16:13
Solarionah, 7.1-1ubuntu2, duh.  :)16:13
* Solarion finishes the transfer before testing16:14
brycetjaalton: great thanks17:27
tjaaltonbryce: I'll have a chat with pitti about how pm-utils/hal and hotkeys interact17:34
tjaaltonthat's basically what we decided17:34
bryceyep, saw the log17:34
bryceI'm going to be meeting up with slangasek, so will be able to look at the issue on his system too17:34
tjaaltondon't know why xorg is uninstallable on i386/amd64, installed just fine here17:35
=== mvo__ is now known as mvo
bryceheading downtown; be back online in an hour or so17:42
mvohello! it seems that (for intel) the xserver claims to be able to do direct rendering when a additional server is started via fusa, but when compiz is started, that does not work18:38
mvois that a know issue? 18:38
mvopitti just told me about it on #ubuntu-devel18:39
mvodidn't it use to not accelerate the additonal xservers, only the first one?18:39
tjaaltonso you get a white screen for the second screen?18:41
tjaaltondon't know why that is..18:42
mvo(well, not me, but martin)18:43
tjaaltonI tried it myself ~1h ago18:43
tjaaltonand saw the saem18:43
mvotjaalton: for hardy (and before) the additional screens were without DRI, no?18:44
tjaaltonyep, think so18:44
tjaaltonbut it does disable it18:45
tjaaltonlooking at the log..18:45
mvoI need to test that with my ati to see if that shows it too18:45
tjaalton(II) GLX: Initialized DRISWRAST GL provider for screen 018:46
tjaaltonmaybe that has something to do with it18:46
mvomakes me wonder if need to add another hack to the compiz startup script and grep for "OpenGL renderer string: Software Rasterizer" in glxinfo18:46
tjaaltonperhaps, doesn't seem like it's able to please compiz18:47
* mvo wishes there was a reliable way to ask "is your opengl HW accelerated, xserver" 18:47
tjaaltonhm, maybe not18:48
mvowell, that is what I do currently, and it keeps lying at me :)18:49
tjaaltonyeah, maybe the swrast-thing lies that it's DRI18:57
bryceback heya18:59
tjaaltonhey hey19:01
brycesteve's not arrived yet19:04
brycetjaalton: so where do we sit with the hotkey bug?  I suppose that's the top of my todo list again now19:05
tjaaltonbryce: to find out if it's just a mapping thing that can be fixed in pm-utils or whatever should listen to them19:06
tjaaltonI'm gathering all the keysyms that I get from the nonworking ones, and see what they should be19:06
tjaaltonon my X6119:07
james_wtseliot: I see you've fixed bug 262906 upstream already. Would it be better to use strptime to produce something like "xorg.conf.20080912201512"?19:16
ubottuLaunchpad bug 262906 in screen-resolution-extra "policyui.py crashed with TypeError in setVirtual()" [Undecided,Confirmed] https://launchpad.net/bugs/26290619:16
james_wrather than "xorg.conf123456.3212"19:16
james_wthanks for fixing it though19:16
tseliotjames_w: it creates a backup with the current date (in Python)19:17
james_wtseliot: yeah, but str(time.time()) produces something where the date isn't obvious to the user19:18
james_wif you use strptime they can easily see what date the backup was made on19:18
tseliotjames_w: ok19:18
tseliotwould you like to fix it and upload it?19:19
james_wI can't upload it19:20
james_wI can provide you with a branch to merge if you like though19:20
tseliotjames_w: yes, that would be great since my branch has evolved too much19:21
james_wtseliot: ah, you would like one based on what is in Intrepid?19:21
tseliotjames_w: yes, please19:21
tseliotjames_w: the one in my bzr branch is meant to work with my patches (in C)19:22
tseliotjames_w: isn't my fix in Intrepid already?19:23
james_wtseliot: apart from that, and the intel bug just discussed it seemed to work well though, thanks19:23
tseliotjames_w: the one which looks ugly to you, I mean19:23
james_wtseliot: I don't think so, I just hit it, and there don't seem to be any uploads19:25
james_wand I just grabbed the source and it matched revision 4, which is before the fix19:25
tseliotjames_w: ok, then I forgot to ask bryce to upload it after the freeze in main19:26
tseliotbryce: can you upload james_w's fix when it's ready, please?19:26
james_wtseliot: I see why you also moved it in to the "try: except:" block that parses the file19:27
james_wtseliot: but it seems like that would leave you without a backup if the file didn't exist19:27
tseliotjames_w: why make a backup of a file which doesn't exist?19:28
james_wsorry, if the file doesn't parse19:28
tjaaltonbryce: I'll be afk for ~2h19:29
tseliotjames_w: let me check the code19:29
tseliotjames_w: I could handle the 2 exceptions separately19:31
tselioti.e. don't make a backup if IOError is caught19:31
tseliotbut make a backup19:31
james_wtseliot: I can just add an "os.path.exists:" check first and make the backup19:31
tseliotjames_w: yes, sure19:32
james_wtseliot: lp:~james-w/screen-resolution-extra/intrepid if you would like to check it19:34
tseliotjames_w: BTW if my patch is accepted there will be no need to set up the screens again on login after setting the virtual resolution19:35
* tseliot has a look at the new branch19:35
james_wyeah, I saw that, it would be pretty cool19:35
tseliotlet's cross our fingers19:37
tseliotjames_w: ok, the code looks good. There's still something else which I would like to fix but I guess it's enough for now.19:41
tseliotthanks a lot19:41
james_wthank you19:41
james_wcan I leave it with you to get that uploaded?19:41
brycetseliot: sure will do 19:42
tseliotbryce: thanks19:42
brycetseliot, james, got a debdiff or patch or gid id I should pull from?19:42
tseliotbryce: can you take the code from James' branch? https://code.launchpad.net/~james-w/screen-resolution-extra/intrepid19:43
james_wbzr diff -c -1 lp:~james-w/screen-resolution-extra/intrepid19:44
james_w"show me the diff of the last revision in that branch"19:44
brycehttp://bazaar.launchpad.net/%7Ejames-w/screen-resolution-extra/intrepid/diff/5 looks good?19:44
* tseliot should learn how to do such tricks with bzr...19:44
bryce$ bzr diff -c -1 lp:~james-w/screen-resolution-extra/intrepid19:45
brycebzr: ERROR: Unknown repository format: 'Bazaar RepositoryFormatKnitPack5 (bzr 1.6)\n'19:45
james_wbryce: are you on hardy?!19:45
bryceoh this is complicated...19:46
brycemy laptops are intrepid, but my main development box (which does builds, file serving, etc.) is hardy19:47
brycealso, my mythtv box is hardy, so any machine I have that needs to view mythtv has to be on hardy too (mythtv client/server versions must match)19:47
bryceanyway, TMI.  I use heavy chrooting and pbuilder for builds and stuff19:48
james_wyeah, the exclamation mark might have been a bit over the top19:49
bryceanyway, I'm still not 100% sure whether the extra overhead is worth the stability for the build box19:50
brycebut doing builds in chroots seems to have eliminated a lot of build goofs I used to run into19:50
bryceand having nfs go away really crimps my style ;-)19:51
* tseliot > bbl19:52
Solariontjaalton: the new mesa wfm19:59
brycejames_w, tseliot: uploaded20:59
tseliotbryce: thanks a lot :-)21:00
brycetjaalton: so slangasek's problem seems to have been driven by the presence of a ~/.Xmodmap.  Since removing that, his keys are working better21:46
tjaaltonbryce: oh, nice21:47
brycetjaalton: also it sounds like pitti's issue more closely resembles mine than mdz's21:47
bryceso it's not sure that anyone has "the same" issue as mdz21:47
tjaaltonman, this is confusing..22:03
tjaaltontrying to stay sane with all these scancodes, keycodes, keysymbols etc..22:03
tjaaltonanyway, I get the same keycodes for hibernate and batter, and yes, they don't work for me either22:04
tjaaltoneh, batterY22:04
tjaaltonthe keycode for battery when using kbd is 241, with evdev it's 24422:06
tjaaltonI guess "something" is hardcoded for 24422:07
tjaaltonactually, it's not the driver that matters, but the rules22:08
tjaaltonno, it's the model after all22:09
tjaaltonif I change rules xfree86->evdev, I get the nice keysym (XF86Foo), but the keycode is the same22:10
tjaaltonthis all with xec22:11
tjaaltonuh, xev22:11
tjaaltonhm, no.. changing the model doesn't change keycodes I get.. normal I guess22:13
brycetjaalton: yeah keyboard troubleshooting is giving me headaches as well22:14
bryceok, I see 244 for battery, and 213 for hibernate22:17
brycehibernate maps to XF86Standby, but battery maps to XF86None or whatever22:17
tjaaltonyeah battery is NoSymbol22:19
brycebtw, you mentioned that the keyboard not waking up bug is fixed upstream; have we pulled in that fix?  If not, should we?22:19
bryceright NoSymbol (it scrolled out of my buffer)22:19
tjaaltonyes we have, evdev master uploaded today ;)22:19
tjaaltonincluding device properties22:20
bryceok cool, I'm just holding off doing an upgrade until I get back home22:20
tjaaltonnah, works flawlessly22:20
brycealright so pitti is seeing the same key id's as me, 213/XF86Standby, and 244/NoSymbol22:20
tjaaltonyes, and so am I22:20
bryceon a thinkpad?22:20
brycelemme check with slangasek22:21
tjaaltonthere are also a couple of other hotkeys that don't seem to do anything22:21
tjaaltonand I don't know what they are supposed to do22:21
brycewhich ones?22:21
tjaaltonkeycodes 200 (disable trackpoint, maybe) and 202 (eject?)22:22
torkel202 is ejecting from dock iirc22:23
tjaaltonalso, there are functions behind the cursor keys (rew, ff, stop, play/pause), that have never worked22:23
tjaaltontorkel: ok, makes sense22:23
tjaaltonoh and zoom does nothing (fn-space)22:24
torkelneither does the thinkvantage button22:25
tjaaltondamn, typos22:26
torkelor the power button22:26
brycepower button?  o_O22:26
tjaaltonright, it should open the logout prompt22:26
brycetjaalton: of those, how many worked under hardy?22:27
brycei.e., how many are regressed?22:27
tjaaltonbryce: can't tell, don't remember :)22:27
torkelbryce: at least mute, screenlock, suspend, hibernate, brightness22:28
torkelnever used the other ones :-)22:28
brycetorkel: when you run xev, do those all give keycodes?22:28
bryce(and are they the appropriate keycodes?)22:29
torkelbryce: I get the same keycodes as tjaalton22:31
torkelbryce: I'm on intrepid too22:32
tjaaltonthe reason why xev doesn't show the radio button or zoom is that the scancode is >25522:32
torkelradio button == Fn-F5?22:33
tjaaltonit works22:34
brycetjaalton: ah interesting22:34
torkelthat one works for me. It switches bluetooth on and off22:34
torkelis that done in hardware?22:35
tjaaltonrunning evtest on the device shows that there are a lot of scancodes not mapped to anything (in the kernel)22:35
tjaaltonor, at least they don't have a fancy name there22:36
bryceI still see nothing from hotkeys via evtest22:37
tjaaltonthat's normal with evdev, since the driver steals them22:38
tjaaltonsame thing if you load the evbug module22:38
tjaaltonit should print the events on dmesg22:38
tjaaltonwell, kernel log22:39
brycetjaalton: slangasek is suggesting that with how fscked up all the acpi stuff is, we ought to have a uds blueprint just for getting all this mess documented as to how things *should* work22:39
tjaaltonbryce: no shit :)22:39
pwnguingiven that the laptop team is basically dad22:40
pwnguinand the one guy who really knew acpi left for redhat22:40
torkelhm, I wonder if there are other bugs involved to. Because if I add Ctrl-Alt-L as shortcut for Lock Screen in gnome-keybinding-properties. It still doesn't lock the screen22:43
torkelsame thing with mute22:45
tjaaltonctrl-alt-l works here22:46
brycetjaalton: ok with evbug loaded, I still see no output for those keys22:49
brycesame with slangasek22:49
tjaaltonbryce: just like I said?-)22:49
tjaaltonoh.. I was unclear22:50
tjaaltonit *should* print event on the log, but can't since the evdev driver steals them22:50
tjaaltonreadint thinkpad_acpi.c..22:51
tjaaltondamn, should get some sleep..22:51
tjaaltonok, will continue tommor, night->23:15
brycetjaalton: see my latest comments on bug 267682 - slangasek and I think it's a kernel bug23:28
ubottuLaunchpad bug 267682 in linux "Hotkeys no longer working in Intrepid on Thinkpads" [Critical,Triaged] https://launchpad.net/bugs/26768223:28

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!