[06:03] <tjaalton> desrt: ok, that's weird..
[06:04] <tjaalton> pwnguin: we can use dbus though, and add the other devices with a daemon like what Alexia_Death has done
[06:04] <pwnguin> oh yea
[06:27] <desrt> tjaalton: any ideas?
[06:27] <desrt> tjaalton: is this the sort of thing that was expected to be working out of the box?
[06:57] <tjaalton> desrt: at some point
[08:07] <Alexia_Death> desrt: with my daemon it already is pretty much a matter of starting the daemon and thats it.
[08:07] <Alexia_Death> desrt: initial configuration is a bit of work.
[08:53] <tseliot> tjaalton: it looks like my patch fixes the problem: https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/322659
[08:53]  * wgrant is back on the planet now.
[08:54] <tjaalton> tseliot: synaptics 1.0.0 was released, and according to the announce those things should be autodetected now and if not, the kernel is buggy
[08:55] <wgrant> tjaalton: There are no changes to that end since 0.99.3
[08:55] <tjaalton> so I'm thinking that these patches might break things for other users
[08:55] <wgrant> Only manpage changes, FDI comments, and float properties.
[08:55] <wgrant> The problem is that the autodetection is strange.
[08:55] <wgrant> It decides that if it can use two-finger scrolling, it will disable edge-scrolling.
[08:55] <tjaalton> wgrant: sure, but I meant the changes between 0.15.x -> 0.99.3
[08:56] <wgrant> It's reasonable, but a complete change in behaviour from what we have traditionally had.
[08:56] <tjaalton> right, and that's something the kernel should tell
[08:56] <wgrant> No.
[08:56] <wgrant> It's policy.
[08:56] <wgrant> Everybody expects touchpads to have edge-scrolling on by default.
[08:56] <tjaalton> Kernels up to excluding 2.6.29 announce multi-touch capabilities for all
[08:56] <tjaalton> synaptics touchpads even if the hardware does not support it. If you have a
[08:56] <tjaalton> such a touchpad, you will need to enable edge scrolling explicitly in the
[08:56] <tjaalton> configuration.
[08:56] <wgrant> But the new upstream policy is to enable it only when two-finger scrolling cannot be enabled.
[08:56] <bryce_> heya
[08:57] <tjaalton> hi bryce_ 
[08:57] <wgrant> Evening bryce_ .
[08:57] <tseliot> tjaalton: my new patch fixes what I broke with another patch therefore I think it's ok to upload it
[08:57] <tseliot> hey bryce_
[08:57] <wgrant> tseliot: May I see this patch?
[08:57] <tjaalton> tseliot: ah, ok :)
[08:57] <tseliot> wgrant: which one?
[08:57] <wgrant> tseliot: The one that isn't in the archive yet.
[08:58] <tseliot> wgrant: https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/320632/comments/53
[08:58] <tjaalton> wgrant: according to the text I pasted, kernel 2.6.29 should be more wise about these issues, but maybe I'm misreading things
[08:59] <tseliot> tjaalton: there's still something wrong in the detection of the touchpad edges for ALPS
[08:59] <wgrant> tjaalton: It's a different, but related, issue.
[08:59] <wgrant> tjaalton: Few people expect two-finger scrolling, but that's all most people will get (even with 2.6.29).
[09:00] <tjaalton> I'm lucky not to have a touchpad, so it all is a bit irrelevant to me :P
[09:00] <tjaalton> BMFH
[09:01] <wgrant> tjaalton: Basically, pre-0.99, nothing was autodetected. Vertical edge-scrolling was always enabled, and 1-, 2- and 3-finger taps always emulated clicks on buttons 1, 2 or 3 respectively.
[09:01] <tjaalton> wgrant: I trust your judgement, so whatever has your stamp-of-approval, I'll upload :)
[09:01] <wgrant> Heh.
[09:01] <wgrant> tseliot's patches are what I would have done.
[09:01] <tseliot> ;)
[09:02] <wgrant> Had I know there was going to be so much bugmail from the default changes, I would have done it myself before I went away...
[09:02] <wgrant> And we finally have float properties.
[09:05] <bryce-sprint> tjaalton: did you get a chance to look at the client limit patch?  I could rework that patch to s/1024/512/ if you haven't already, that should be pretty simple
[09:05] <bryce-sprint> tjaalton: the hotel wireless here is ultra slow though
[09:07] <tjaalton> bryce-sprint: well, the proto patch uses 16bits instead of 8, so maybe 9 would do for 512, but I guess 16 doesn't hurt. the one for xorg-server is trivial
[09:10] <tjaalton> gotta run now ->
[09:14] <wgrant> Huh, DRI2 actually works.
[09:14] <bryce-sprint> wgrant: what did you need to do to flip that on?
[09:15] <wgrant> bryce-sprint: Just change the AccelMethod to UXA.
[09:15] <wgrant> It's only a little bit quirky with some menus.
[09:15] <bryce-sprint> ok good
[09:16] <bryce-sprint> wgrant: can you file bugs with the issues you find?
[09:17] <wgrant> bryce-sprint: Against what? -intel?
[09:17] <tseliot> when I tried UXA X started and when I launched gnome-terminal X froze (together with the kernel)
[09:18] <wgrant> The menus do this very strange bright fadish thing when coming in and out.
[09:18] <wgrant> But i915 with UXA and DRI2 works fine, with redirected direct rendering.
[09:23] <wgrant> tseliot: Why do you go back to disabling multi-finger taps in your patch in commennt #53?
[09:23] <wgrant> Disabling on non-MacBooks, that is.
[09:23] <tseliot> wgrant: because it breaks drag and drop with physical buttons
[09:24] <tseliot> which is not what we want ;)
[09:26] <wgrant> tseliot: You mean it does strange scrolly thing and releases early?
[09:26] <wgrant> There must be better ways to fix that, given that I'm sure it worked before.
[09:27] <tseliot> if you have one finger on the touchpad and one to hold down the physical left button drag and drop would simply not work
[09:27] <bryce-sprint> wgrant: yes 
[09:28] <tseliot> and the cursor will just move
[09:30] <wgrant> tseliot: I can drag and drop almost fine - the only problem is that it drops when I take a finger of the touchpad, rather than off the button.
[09:41] <tseliot> hmm...
[11:01] <popey> before I file a bug report against xrandr/xorg in jaunty, I just wanted to ask if there was some fundamental change in the intel driver that might cause regressions/breakages?
[11:02] <popey> (specifically it ignoring a resolution I put either on the command line with xrandr and also if I put the correct modeline in xorg.conf)
[11:19] <tjaalton> popey: change since when? the driver has supported randr-1.2 since feisty, so forcing a mode needs some work
[11:22] <popey> tjaalton: well I used a little bit of gtf/xrandr magic as recently as a week or so ago, and now xorg just barfs when i try to set it to a specific res 
[11:23] <tjaalton> popey: hmm, that sounds odd
[11:24] <popey> tjaalton: worth filing a bug ?
[11:24] <tjaalton> popey: probably.. where are the errors from?
[11:24] <popey> there is no error, the screen just goes to a different mode - uniform colour of brown, no icons, no panels
[11:25] <popey> system isn't locked up, i can restart gdm and get back in
[11:25] <tjaalton> huh, weird
[11:25] <popey> xorg.0.log doesn't even make reference to the resolution i set in xorg.conf
[11:26] <popey> i know it's reading the xorg.conf because i added the necessary wacom stuff and that works
[11:26] <tjaalton> you need to do something like here to force a mode: http://users.tkk.fi/~tjaalton/foo/xorg.conf
[11:28] <popey> I had something similar, with a separate section for modes
[11:29] <popey> have modified it to be more like yours and it still ignores the res I put in
[11:30] <popey> http://popey.com/~alan/xorg.conf
[11:30] <tjaalton> logfile might help
[11:30] <popey> http://popey.com/~alan/Xorg.0.log :)
[11:32] <tjaalton> what if you add 'Option "monitor-LVDS" "Generic Monitor"' to the device section?
[11:36] <popey> oh I see, in the logs it's trying to set VGA to 1280x720?
[11:36] <tjaalton> yes
[11:37] <popey> ok, adding that option I get a lot of blinking but no x on the panel
[11:37] <tjaalton> another logfile too?-)
[11:38] <popey> http://popey.com/~alan/Xorg.0.log_2
[11:39] <popey> http://popey.com/~alan/xorg.conf_2
[11:39] <popey> oh, my bad
[11:40] <popey> i set the option in the wrong place
[11:41] <tjaalton> does it work if you move it?
[11:41] <popey> heh, no
[11:41] <tjaalton> yeah, according to the logfile it did try 12x7
[11:41] <tjaalton> but I've no idea why it doesn't work
[11:41] <tjaalton> hmm, are you sure it's a 75Hz screen?
[11:42] <popey> i used gtf to generate that modeline, and specified "1280 720 60"
[11:42] <tjaalton> oh
[11:42] <tjaalton> I misread it
[11:44] <popey> worth me filing a bug do you think?
[11:44] <tjaalton> yeah
[11:45] <popey> although from the xorg log it seems to be using 1280x720 for the external VGA still and autodetecting LVDS
[11:46] <popey> oh, then tries later
[12:56] <popey> tjaalton: further investigation reveals that actually my laptop can't switch to _any_ resolution other than the native one
[13:15] <popey> tjaalton: fyi if you're interested i filed bug 324286 about it. thanks for the help
[13:17] <tjaalton> popey: ok thanks
[18:31] <jcristau> hrm. patches.ubuntu.com isn't getting updated?
[20:15] <tjaalton> seems like it
[21:26] <maxb> Hi, after the recent libgnome change to use the xorg detected dpi value for font sizing, my fonts are huge
[21:26] <maxb> However, "xrandr --verbose" is getting the correct screen dimensions
[21:27] <maxb> Hardware is an Acer Aspire One
[21:27] <maxb> Can someone guide me to filing a useful bug? Thanks.
[21:30] <jcristau> hrm.
[21:30] <jcristau>     - Add libxinerama1 to build depends.
[21:30] <jcristau> really?
[21:38] <tjaalton> sounds odd
[21:40] <tjaalton> maxb: just use 'ubuntu-bug -p xserver-xorg-video-FOO', that should include the useful logs
[21:51] <maxb> tjaalton: xdpyinfo says the correct resolution and physical dimensions...does it still make sense to file against the driver?
[21:52] <tjaalton> maxb: the logfile will tell
[21:52] <maxb> ok
[21:53] <jcristau> (probably not. but then the font size should be correct.)
[21:55] <maxb> LP 324518 filed, anyway
[21:58] <tjaalton> (==) intel(0): DPI set to (96, 96)
[21:59] <jcristau> tjaalton: i think that one's misleading
[21:59] <jcristau> it says that here, too, but xdpyinfo says 125x125
[21:59] <tjaalton> hmm, nice
[22:01] <superm1> tjaalton, dpkg-shlibdeps complains elsewise...
[22:03] <tjaalton> superm1: hum, ok
[22:03] <jcristau> superm1: okay. i guess that makes sense. blobs ftl.
[22:03] <tjaalton> maxb: could be that your font sizes are just too large?-)
[22:03] <superm1> yeah. pretty much everything in that upload was working around ugly behavior that happens with the blob :(
[22:04] <tjaalton> maxb: I believe the defaults have been changed in the past to work around some issues, so maybe they should be changed again
[22:05] <tjaalton> hmm, although they should be smaller now
[22:05] <maxb> tjaalton: Well, it could be that everything's working as designed, but if that's the case, then every Aspire One user is going to get their fonts blown up to an unhelpful size when upgrading
[22:05] <tjaalton> maxb: I'm not sure what's going on, but probably the guys at the sprint will notice it too, and do something about it :)
[22:13] <maxb> ooh, good point
[22:13] <maxb> Hopefully there'll be a few netbooks there
[22:26] <maxb> tjaalton: I just updated a second machine, with the same result - a distinctly excessive increase in font size. I suppose things are working as designed, but this design is liable to annoy people upgrading, I suspect
[22:29] <tjaalton> maxb: AIUI the effect should be the opposite, but oh well :)