[08:24] <tjaalton> http://lwn.net/Articles/305047/
[08:28] <wgrant> tjaalton: Saw that a few days ago. Haha.
[08:28] <wgrant> THey must have better things to flame about.
[08:28] <wgrant> seb128: I have an SRU for g-s-d.
[08:29] <tjaalton> wgrant: yeah, it's the small changes that annoy some people the most :)
[08:29] <wgrant> seb128: Bug #280148, and I've had the patch committed upstream. Am I OK to start the SRU process?
[08:29] <seb128> wgrant: hi, it's monday morning and I got over 700 bugs mails during the weekend so add yours to the list
[08:30] <seb128> let me look
[08:30] <wgrant> seb128: Sure, no rush.
[08:31] <seb128> wgrant: the change seems to be a sru candidate indeed, start on it and subscribe the sponsor team if you need sponsoring
[08:31] <wgrant> seb128: Great, thanks.
[08:47]  * wgrant wonders about u-m-s latency.
[10:20] <mvo> superm1: did you had a chance to check if your card works with fglrx from intrepid? 
[11:47] <Q-FUNK> wgrant: to answer the question, aptitude handled the dist-upgrade from hardy.
[11:47] <wgrant> Q-FUNK: That is not allowed.
[11:47] <Q-FUNK> where is that said?
[11:47] <wgrant> Q-FUNK: The dist-upgrader is the only supported upgrade mechanism.
[11:48] <wgrant> ie. update-manager or do-release-upgrade
[11:48] <wgrant> https://help.ubuntu.com/community/IntrepidUpgrades
[11:49] <wgrant> You will find a single reference to dist-upgrade there, and it isn't used as an action to apt-get or aptitude.
[11:50] <Q-FUNK> that doesn't say that apt-get or aptitude are not allowed.
[11:50] <wgrant> They haven't been supported in Ubuntu for a *very* long time.
[11:52] <wgrant> Anyway, have you tried to suspend?
[11:53] <Q-FUNK> I just rebooted without the xorg.conf now.  
[11:53] <Q-FUNK> let's try it
[11:53] <Q-FUNK> brb
[11:53] <tseliot> mvo: new NVIDIA legacy drivers (compatible with X.org) are available in intrepid-proposed now. Maybe update manager can stop migrating users to "nv" after these drivers are moved to the stable repositories
[11:54] <mvo> tseliot: sure. both versions are updated in -prpopsed?
[11:54] <tseliot> mvo: yep
[11:55] <tseliot> mvo: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-96/+bug/251107
[11:58] <mvo> thanks tseliot
[11:59] <tseliot> mvo: you're welcome
[12:02] <Q-FUNK> wgrant: nope.  bug still present. :(
[12:03] <wgrant> Q-FUNK: So your hardware manages to partly vanish? Great.
[12:03] <wgrant> Q-FUNK: Which setting is dropping?
[12:03] <Q-FUNK> wgrant: maybe.  the strange thing is that going to the gnome mouse preference capplet and manually clikcing right, then left again restores it.
[12:04] <Q-FUNK> left-handed buttons
[12:04] <wgrant> Q-FUNK: On all devices?
[12:04] <Q-FUNK> which devices?
[12:05] <wgrant> Does the left-handed setting drop from all devices, or just the touchpad?
[12:05] <Q-FUNK> this laptop only has a touchpad.  4 buttons.  2 above and 2 below.  mirrored by X default.
[12:06] <Q-FUNK> it also has a trackpoint, but it shares the buttons used by the touchpad
[12:06] <wgrant> Ah, lots of people use an external mouse as well.
[12:06] <wgrant> OK, let's see...
[12:06] <wgrant> Try flipping horizontal edge scrolling on, and check the Synaptics Edge Scrolling property on the device before and after suspend.
[12:07] <Q-FUNK> this Dell D430 was a common sight at the last IDS in Prague.  other people had the previous D420 also.  there should be plenty of people who can test this, but I'm not sure if any of them are left-handed
[12:07] <wgrant> As well as checking if it still works after suspend, of course.
[12:07] <Q-FUNK> all touchpad options are enabled, here.
[12:08] <wgrant> And horizontal scrolling persists over a suspend/resume?
[12:08] <Q-FUNK> good question.  the only place where I sometimes need it is in forefox.
[12:08] <Q-FUNK> firefox
[12:08] <Q-FUNK> let's try.
[12:08] <Q-FUNK> brb
[12:08] <wgrant> I test it by checking if the bottom edge moves the cursor orr not.
[12:09] <Q-FUNK> ok
[12:09] <Q-FUNK> doesn't move the cursor here
[12:09] <Q-FUNK> vertical scrolling works, so I'd presume that horizontal does too.  I just dont have a web site with fixed page size to test with
[12:10] <wgrant> Right.
[12:10] <wgrant> Now, does it still work after a suspend and before you reset settings?
[12:10] <Q-FUNK> ah, wait. I purposely downsized the firefox window.  horizontal works too.  let's suspend and try this again.
[12:10] <Q-FUNK> brb
[12:13] <Q-FUNK> horizontal scrolling NOT restored after suspend.
[12:13] <Q-FUNK> oh... wait.  it takes a while to restore, but it eventually comes back
[12:13] <wgrant> Hmmmmmmmmmmmmmmmmmmmmmmmmmmmmm.
[12:13] <wgrant> But the button mapping is still not back?
[12:14] <Q-FUNK> indeed not
[12:14] <wgrant> Curses.
[12:14] <Q-FUNK> hm. wait. that came back too.
[12:14] <wgrant> Check Xorg.0.log to see if the device disappears and reappears now.
[12:14] <wgrant> Hmm.
[12:15] <Q-FUNK> could it be dependant upon touchpad requring non-default settings, if the buttons are attached to it, to restore buttons too?
[12:15] <wgrant> No.
[12:16] <Q-FUNK> hm
[12:16] <Q-FUNK> odd
[12:19]  * wgrant -> bed
[12:21] <Q-FUNK> ok
[12:21] <Q-FUNK> good night!
[14:39] <superm1> mvo, so it turns out the workstation quality r3xx (FireGL) aren't broke; it's only the consumer grade
[14:39] <superm1> mvo, so that's why mine still works
[14:39] <superm1> and yes it does work on Intrepid
[14:56] <mvo> superm1: ok, thanks for testing this
[15:09] <tjaalton> hehe, bug 292993
[15:09] <tjaalton> lazy ubottu.. https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/292993
[15:23] <mvo> tjaalton: what should be done about bug #292774 ? it seems like (some people) are not happy with the automatic xorg.conf rewrite
[15:25] <tjaalton> mvo: well, not commenting them out shouldn't hurt, since when HAL is used they are just ignored (for mice/keyboards anyway)
[15:26] <mvo> hm, but his setup would be broken anyway in this case, right?
[15:26] <tjaalton> yes
[15:26] <mvo> ok
[15:27] <mvo> IIRC one in the X team asked me to add the code to comment out the input devices because it would break something with "synaptics" (from memory) ? 
[15:27] <mvo> is that no longer true ?
[15:27] <tjaalton> ok, could be..
[15:28] <tjaalton> evdev has since been modified to not grab the devices explicitly, but AIUI there were some problems and still might be
[15:28] <tjaalton> wgrant is the synaptics hero, I don't have one :)
[15:35] <tseliot> tjaalton: basically the InputDevice sections caused problems to touchpads tapping, etc.
[15:36] <tseliot> removing such section solves the problem
[15:37] <tseliot> tjaalton, mvo: I wasn't aware of how it could affect multi-seat setups though
[15:37] <tseliot> of course having more information in the bug report will help me understand what went wrong
[15:38] <mvo> tseliot: me neither, I think its not a big deal, given that the setup would have been broken even without the modifications
[15:38] <mvo> tseliot: at the very least he had to add this "NoAuto" option (forgot the exact name)
[15:38] <mvo> so no (more) harm done by the script, still would be nice to know more aobut it
[15:39] <tseliot> right
[15:50] <seb128> any idea if bug #290674 could be an xorg issue?
[15:50] <tjaalton> seb128: yes, probably evdev
[15:51] <seb128> tjaalton: ok thanks
[15:51] <seb128> I'll reassign the bug
[15:51] <tjaalton> thanks
[15:53] <seb128> tseliot: could you look to bug #287062 ?
[15:53] <seb128> ups
[15:53] <seb128> bug #287082
[15:54]  * tseliot has a look at the bug report
[15:56] <tseliot> seb128: I think 287082 is a duplicate of 287062
[15:56] <tseliot> my quick fix was uploaded to jaunty
[15:57] <seb128> tseliot: feel free to close it as duplicate
[15:57] <tseliot> and to intrepid-proposed
[15:57] <tseliot> ok
[15:57] <seb128> tjaalton: ok, bug #264196 seems to be the keyboard issue
[15:57] <seb128> could somebody in the xorg team triage it?
[15:58] <tjaalton> seb128: sure, I think it's known upstream too
[15:58] <tjaalton> later ->
[15:58] <seb128> bugs.freedesktop.org seems to not reply
[15:59] <seb128> tseliot: bug #284630 is yours too
[15:59] <seb128> though don't change it in a sru because that would break translations
[16:02] <tseliot> seb128: shall I fix it only in jaunty?
[16:02] <seb128> tseliot: yes, not worth breaking the translations for intrepid
[16:02] <tseliot> right
[16:03] <tseliot> and that error shouldn't show up unless the virtual resolution can't be applied
[16:35] <jcristau> tseliot: padding bytes in the wire protocol are necessary for alignment (re your question on xcb@)
[16:36] <tseliot> jcristau: alignment of what?
[16:36] <jcristau> of the data sent between server and client
[16:39] <tseliot> jcristau: is there documentation on this?
[16:39] <jcristau> see the spec, of the protocol headers, i guess
[16:40] <jcristau> in this case, xRRSetCrtcConfigReq in randrproto.h has a 2-byte 'pad' field after 'rotation'
[16:40] <jcristau> and the output list follows the xRRSetCrtcConfigReq
[16:41] <jcristau> in general, every 2-byte field is aligned on a 2-byte boundary, and every 4-byte field on a 4-byte boundary
[16:43] <tseliot> ok
[16:43] <tseliot> thanks for the explanation
[16:43] <jcristau> np
[16:44] <jcristau> oh, also every request's length is a multiple of 32 bits, so the next one is aligned properly
[16:45] <tseliot> aah
[16:50]  * Ng curious, is there some kind of api for getting events from a touchpad? I expressly don't want to use mine for mouse events, but I'm curious if I could get some funky pinchyzoomyswipey gestures going
[16:50] <Ng> like, flicking it to navigate workspaces
[17:16] <pwnguin> theres xinput
[17:17] <pwnguin> and i saw a gestures thing
[17:17] <pwnguin> but honestly, i dont really like them
[17:20] <Ng> pwnguin: I generally don't with mice, but I think they work with a touchpad, specifically because I have an iphone and being able to do the pinchyzoomy stuff is excellent
[17:22] <pwnguin> oh
[17:22] <pwnguin> thats a different thing
[17:22] <pwnguin> a) your device has to support that
[17:23] <pwnguin> and as usual, apple snapped up an exclusive on the patented hardware that does multitouch
[17:24] <Ng> bah
[17:25] <pwnguin> do you have a touchpad right now?
[17:35] <Ng> yeah, but I disable it in the BIOS because I hate using them for mouse input ;)
[17:38] <pwnguin> macbook?
[17:47] <Ng> pwnguin: nah, thinkpad
[17:47] <pwnguin> then i dont think you get pinchzoom
[17:48] <pwnguin> you've probably got a synaptic device that does resistance calculation
[17:48] <Ng> well that sucks
[17:48] <Ng> maybe I could stick my iphone to the laptop and use that as a network touchpad ;)
[17:49] <pwnguin> someone had this hilarious laptop
[17:49] <pwnguin> 17 inch display, and a wacom tablet below the keyboard
[17:50] <Ng> :o
[17:51] <pwnguin> mine's built into the display, like sane people's laptops
[18:13] <Ng> pwnguin: tablet thing? :)
[20:16] <pwnguin> yea
[20:17] <pwnguin> hey uh, about three hours before the release my intrepid install started kernel panicing
[20:17] <pwnguin> i think its the video driver
[20:17] <pwnguin> is nvidia known bad?
[21:59] <Ng> how would you guys feel about an SRU for https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/282387 ?
[21:59] <Ng> I'm testing the patch atm
[22:03] <james_w> can someone help me reassign bug 293209 to the correct place?
[22:03] <james_w> I suspect driver, but I'm not positive
[22:07] <superm1> bryce, I think i might have a new piece of useful data in the debugging of that fn+brightness makes things go wacky.  If you run in failsafe terminal, you are somehow receiving a key release event *before* a keypress event...
[22:07] <bryce> superm1: weird
[22:08] <superm1> bryce, yeah i'm not even sure how to debug that.  i'm gonna have to compare with 8.04 and see if it's new.  showkey isn't even showing that event
[22:09] <bryce> Ng: is 282387 a regression?  If not, I'd say leave it for Jaunty
[22:09] <bryce> superm1: ok
[22:10] <Ng> bryce: well previously one would set the input properties as driver options in xorg.conf and they'd stick. right now they are set with xinput and lost on suspend/resume. functionally it's a regression, but it's new code, so maybe that doesn't count
[22:12] <jcristau> if you set them in something.fdi, they don't persist?
[22:12] <bryce> james_w: Looks like the user has Virtual set to 2384x768 
[22:13] <Ng> jcristau: I've not tried that route at all
[22:13] <bryce> (EE) intel(0): Mode 1280x1024 does not fit virtual size 2384x768 - internal error
[22:13] <bryce> james_w: that's listed several times in the Xorg.0.log.
[22:13] <jcristau> Ng: that's pretty much today's equivalent of setting them in xorg.conf
[22:13] <bryce> james_w: presumably gnome-control-center needs to take care not to set the y value too low when it hardcodes Virtual, or something
[22:14] <james_w> bryce: I'll ask if they used the Virtual setting thing
[22:14] <james_w> thanks
[22:15] <bryce> james_w: if you get their xorg.conf that'd be proof of it
[22:15] <james_w> http://launchpadlibrarian.net/19299532/xorg.conf
[22:15] <james_w> so it is set
[22:15] <bryce> yep
[22:16] <Ng> jcristau: would that be rewritten on resume? re-setting them with xinput after suspend/resume is what's broken, so presumably they wouldn't be able to persist via fdi either?
[22:16] <bryce> james_w: my guess is they did it via screen-resolution-extra
[22:16] <Ng> s/rewritten/reread/
[22:16] <james_w> bryce: thanks, I'll enquire
[22:17] <bryce> james_w: also talk with tseliot; perhaps some logic needs added to g-c-c to not set X or Y Virtual below some threshold or something
[22:18] <tseliot> bryce: maybe the virtual resolution was set also in clone mode, just like in the bug which I have recently fixed (still in proposed)
[22:18] <jcristau> Ng: maybe i'm not thinking of the right bug..
[22:18] <bryce> tseliot: ah could be
[22:19] <tseliot> bryce, james_w: this bug: https://launchpad.net/bugs/287062
[22:23] <superm1> bryce, yeah that keypress/keyrelease order is definitely a regression from hardy, i'm wondering if this is the root of that problem now...