[10:20] tjaalton: why can't I find the source code of xserver-xorg-input-synaptics (the one in Intrepid) here? https://launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics [10:21] tseliot: because it's xfree86-input-synaptics [10:21] s/input/driver/, even [10:21] right [10:22] tjaalton: xfree86??? [10:22] it's just a name [10:22] yes, I know [10:23] that's what the tarball name used to be [10:23] upstream [10:23] I'll have a look at the code since my touchpad is not very responsive with the latest release of the driver [10:24] ok [11:58] tjaalton: I have tracked down and fixed the problems with my touchpad [11:58] I had to change the values of only 3 variables in synaptic.c [11:59] what shall I do now? Send a patch to upstream? [12:05] tseliot: you changed some defaults? [12:08] tjaalton: yes, RTCornerButton RBCornerButton and MaxTapMove [12:08] I set them back as they were in the last version which worked for me [12:09] you should check git master then [12:10] link? [12:10] gitc.fd.o? [12:11] huh? [12:11] sorry, cgit.fd.o :) [12:13] or http://gitweb.freedesktop.org/?p=xorg/driver/xf86-input-synaptics.git;a=summary [12:13] git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-input-synaptics [12:14] thanks a lot [12:14] *CornerButton are off by default? [12:14] yes [12:14] that probably won't change [12:15] anyway, you can change it with xinput [12:15] if the gui doesn't support it yet [12:16] gui? [12:16] which package? [12:16] maybe I can fix it myself [12:16] the gnome mouse capplet [12:16] gnome-control-center probably [12:17] ok [12:17] I'll have a look at it [12:19] BTW when building the package it complained about the lack of a README and of a TODO file [12:24] hmm... synaptic.c has changed a bit [12:36] tjaalton: I had a look at the gnome-control-center (the one in trunk in the gnome svn) and they removed the touchpad tab from the gnome-mouse capplet [12:38] tseliot: no, look at the ubuntu package [12:38] wgrant made a new patch for it [12:39] tjaalton: ok, I didn't know. Let me have a look [12:41] * wgrant is fairly sure it works. [12:42] wgrant: what does it do exactly? [12:42] tseliot: What do you mean? [12:42] what does the patch do? [12:43] your patch [12:43] It gives us a Touchpad tab that uses XInput properties to control the touchpad. [12:43] Actually, the g-c-c one just sets gconf stuff. [12:43] g-s-d does the dirty work. [12:44] ah, sorry I should have read patch 26 [12:45] wgrant: I would like to make it possible to enable right click by tapping on the right side of the touchpad [12:45] it should be just additional line of code [12:45] tseliot: One can do that for corners. [12:45] But I'm not sure about sides. [12:46] It's easy enough to add. [12:46] yes, for corners [12:46] They just removed that from the defaults upstream, right? [12:46] yes [12:46] Are you able to work out how to hack it into both? It's fairly obvious, I think. [12:47] yes, it is [12:47] I already deal with a multi-value one somewhere. [12:47] at first I modified the driver but then, after talking to tjaalton, we came to the conclusion that I should edit the ui [12:48] the maxtapmove should still be fixed in the driver though [12:48] master uses autoscale for maxtapmove [12:48] and what would kde users do? [12:48] switch the desktop? [12:48] KDE users would get their own solution. [12:48] As they don't use g-s-d, I suppose. [12:48] tjaalton: yes, I noticed the change. What do you suggest that we do? [12:49] wgrant: I'm asking since I use both desktops [12:49] I'll talk to Riddell about that [12:49] tseliot: I suggested that you tried the master version of synaptics to see how it works for you :) [12:50] tjaalton: is there a script to update the source of the deb package from git or shall I do a make && make install? [12:50] just copy the debian dir on the git clone'd dir [12:50] in [12:50] ok [12:53] * tseliot > lunch. Bbl [12:53] Um. [12:53] Interesting autodetection changes upstream. [12:53] Edge scroll being on by default if double-tapping can't be detected, and off if it can. [12:54] And two-finger tapping the opposite. [12:54] heh [12:57] Er, two-finger scrolling. [12:57] Perhaps a good idea, but it is going to confuse a lot of people. [13:52] tjaalton: tapping is completely disabled with the driver from git [13:52] and the cursor moves more quickly [13:53] ok [13:54] tjaalton: can't we just change the maxtapmove in the driver we have in Intrepid and make users modify the right clicking through a GUI? [13:54] rather than pulling the latest driver from git [13:55] I just wanted to know how it behaves [13:55] ah, ok [13:55] setting maxtapmove back to 200 probably should be done [13:57] tap to click is teh evil [13:57] :) [13:57] tjaalton: 220 please [13:59] tseliot: is it such a big deal?-) [13:59] that was the value which was previously used [13:59] * tseliot considers blackmailing tjaalton... [14:00] :-P [14:00] hmm ok, according to the ml discussions it was said to be 200, but git should know [14:00] :) [14:02] send a crate of beer and I'll deliver the new driver on a velvet cushion ;) [14:19] canonical - 10 patches to x.org 0.0466% [14:20] i wonder if that includes the time during which daniel stone was employed [14:21] nope [14:22] that was quite an attack from gregkh.. [14:22] and hardly constructive [14:24] it was also quite true, from what i can tell, so.. [14:26] I wonder where progeny falls on that list ;) [14:27] progeny doesn't exist anymore [14:27] so? [14:28] so it's not relevant? [14:30] i think it might be representative of a different model than say SuSE or RedHat [14:38] wgrant: I have never dealt with gconf before and I was wondering how keys such as /desktop/gnome/peripherals/mouse/tap_to_click are connected to real properties [14:40] or how/where do I find names such as "vert_scroll_toggle", etc.? [14:57] ah, they are in libgnome... [15:05] this still doesn't tell me how a new gconf key can be connected to, say, RTCornerButton [15:06] * tseliot looks in the gnome-settings-daemon [15:15] jcristau: so I just got an X server running -intel in the infinite loop state [15:15] gdb is mostly refusing to attach to it though [15:16] the first time, it said: /build/buildd/gdb-6.8/gdb/linux-nat.c:988: internal-error: linux_nat_attach: Assertion `pid == GET_PID (inferior_ptid) && WIFSTOPPED (status) && WSTOPSIG (status) == SIGSTOP' failed. [15:16] and now it's just hanging when it tries to attach [15:16] yay [15:17] so I'm not sure I can be any more useful than I was when this happened and I didn't attach gdb ;/ [15:20] and it looks like I have to reboot now, X will respond to a -9, but segfaults thereafter [15:22] wgrant: ok, I understood how it works. Ignore my previous questions [15:22] Ng_: maybe disabling dri helps [15:23] jcristau: it might help it not crash on me I suppose, but it won't help me find the bugs :) [15:24] Ng_: it might help narrow down the bug, too, if gdb doesn't want to cooperate [15:25] mebbe [15:25] argh, now X crashed right after the desktop finished loading [15:25] I really appreciate all the work Intel are doing, but their drivers seem to be a bit.... interesting [15:34] what the deuce, it segfaulted again after reboot [15:34] I'm really starting to wonder if there is something wrong with this hardware === Ng_ is now known as Ng [15:35] Windows seems to be entirely stable on it though [15:46] and now it's looping again. This was never entirely stable, but it's never completely broken on multiple successive boots before [15:55] tjaalton: I can implement top-right bottom-right tapping for the right click in the gnome-control-center, however it would be too much work to do in for KDE 4 too (at least for Intrepid). Can't we restore hardy's behaviour in this regard, so that if users enable tapping they get automatically the right click too? If they disable tapping my changes to the driver won't affect them. What do you think? [15:56] tjaalton: this would mean that we keep wgrant's patch as it is and modify only the driver so that it behaves as it used to do in Hardy [16:01] federico1: I have updated screen-resolution-extra in addition to what I wrote in the email which I sent you [16:54] tjaalton, federico1: I might have missed your replies because of problems with my Internet connection [16:55] you didn't miss anything [16:56] jcristau: ok, thanks [17:08] tseliot: you don't need to care about kde [17:09] tseliot: oh, I hope to start checking it out today or tomorrow (been fixing other stuff) [17:09] tseliot: I haven't replied yet :) [17:09] tjaalton: I do care about it because I use gnome on the desktop and kde 4 on my laptop [17:10] federico1: ok, no problem [17:11] tjaalton: I hope to fix this by adding the support for input to X-Kit in Ubuntu 9.04, however I would like the right click to work on 8.10 too [17:12] tjaalton: would it be a problem to restore Hardy's behaviour? [17:13] tjaalton: I could write a patch which we could use only in Intrepid [17:18] tseliot: please do [17:19] tjaalton: ok, great, I'll do it [17:31] still no xserver 1.5 support in fglrx 8.9 [17:42] yes, I know... [17:42] an SRU will be required after Intrepid is released [18:22] tjaalton, bryce: I have prepared a patch for the touchpad and I have also the source with the changelog, etc. ready. Shall I file a bugreport and post the links to the files there? [18:22] tseliot: yep [18:22] ok [18:35] bryce, tjaalton: here's the link (and yes, I know that main is frozen): https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/271823 [18:35] Ubuntu bug 271823 in xfree86-driver-synaptics "[intrepid] touchpad less responsive and top/bottom-right corner tapping disabled" [Undecided,New] [18:41] frozen for alpha6 [18:41] tseliot: please attach just the patch [18:41] since the driver is maintained in git [18:41] tjaalton: ok [18:45] tjaalton: ok, I posted the link to the patch [18:45] should that patch also go upstream? [18:45] bryce: no, since upstream code has changed too much [18:45] ok [18:45] bryce: this is just a temporary fix to restore Hardy's behaviour in Intrepid [18:46] gotcha [18:47] * tseliot > dinner. Bbl [19:23] tjaalton: btw have you put in for sponsorship for the uds? [19:25] bryce: nope, not yet anyway. I'll ask my boss first if he's ready to send me there like before ;) (to get the daily allowance etc) [19:26] cool. looks like the procedure is a bit different this time around [19:27] instead of me putting in names directly, there's a form to fill out and you pick a brainstorm idea to champion. the due date for that is the 25th [19:27] yep, I even poked brainstorm.u.c a bit.. what a mess :) [19:28] yeah [19:28] just pick something that's already done ;) [19:28] and I even commented on the one that demanded widescreen resolutions for failsafe [19:28] ! [19:28] heh [19:29] okay..... [19:31] tjaalton: btw, I'm getting to understand acpi-support quite a bit better [19:31] bryce: so, should we purge it?-) [19:31] no, but it needs some serious work [19:31] I definitely agree we need to close the gap with debian on this [19:32] unfortunately it's not so simple as to re-use their package [19:32] acpi-support was mjg's brainchild, no? [19:32] like 80-95% we can probably use as is; there's some bits that are there to delete stuff from the ubuntu package, which would need to be redone [19:33] also debian and us have very different debian/ directories, that would need to be sorted out [19:33] pwnguin: it started life as some scripts from him, but as I gather, it was mainly put together and maintained by another gyuuuuuuy [19:34] dah, damn keyboard repeats ;-) [19:34] well, i saw that it was orphaned in debian [19:34] and someone picked it up from mjg, but i havent paid much attention to it otherwise [19:34] Thom May [19:35] pwnguin: in Debian Bart Samwel has been extremely active on maintaining it [19:35] it kinda seems like a competitor to HAL [19:36] aiui, it wrappers HAL [19:36] huh [19:36] or at least the debian version does [19:36] our version lacks this (which I think possibly might be the source of some of our recent hotkey/acpi issues) [19:36] well, i just looked enough at it to see if the toshiba scripts did anything relevant to me, and it didnt =/ [19:37] (ages ago) [19:37] hmm. tab works, and alt works. wonder what alt+tab doesn't [21:10] bryce: shoud bug 248521 not be an issue anymore? [21:10] Launchpad bug 248521 in xserver-xorg-input-vmmouse "vmmouse seems to register incorrect x,y values for mouseclick" [High,Confirmed] https://launchpad.net/bugs/248521 [22:23] * wgrant wonders what ATI thinks they're playing at. [22:26] wgrant: they want to see everyone switch to radeon [22:26] or buy nvidia hw [22:30] jcristau: Heh. [22:57] bdmurray: regarding 248521, talk to timo to be sure [22:59] bryce: okay, I noticed an install I was testing today had no mouse section [23:04] bdmurray: right, it now uses evdev automatically [23:54] is anyone else seeing the intel driver getting wedged when they unlock their screen sometimes? [23:56] nope [23:56] you're on i855 still yes? [23:56] is it hanging or crashing? [23:58] 965 [23:58] I get the background and a cursor, but everything else is wedged, and the log has messages about the server looping [23:59] I've had it a few times on G45, but not in the same circumstance, that was more logging in related