[01:07] <emma> Ever since edgy doing what is on this link made my logitech marble mouse work with scroll wheel ability -- http://ubuntuforums.org/showthread.php?t=169423
[01:07] <emma> It worked in edgy, feisty, gutsy, and hardy. 
[01:08] <emma> But now in Intrepid some how X has changed and now I put the same stuff in there and it does not change the behavior of the mouse at all.
[01:08] <emma> Does anyone have any ideas?
[05:06] <tjaalton> morning
[05:07] <tjaalton> emma: input-hotplug means that evdev "steals" all your input devices
[05:08] <emma> so that's a bug?
[05:08] <tjaalton> emma: so that's why "mouse" no longer works unless you do other things 
[05:08] <tjaalton> no
[05:08] <emma> i see. what other things should a person do?
[05:09] <tjaalton> you can use 'xinput' to set the options you like (during a session start, for instance.. GUI support coming later), or add an fdi file which does the same
[05:09] <tjaalton> which is persistent
[05:11] <emma> to me it sounds much more complicated than the old way.
[05:11] <tjaalton> maybe
[05:12] <emma> but ubuntu's raison de'tre is to be easy.
[05:12] <tjaalton> or you can add 'Option 'AutoAddDevices "false"' to the ServerFlags section
[05:12] <tjaalton> and specify keyboard and mouse like before..
[05:13] <emma> i don't want to mess things up if it was made this way now there must be some good reasons.
[05:13] <emma> i would just like my marble mouse to be able to scroll wheel effect again.
[05:13] <tjaalton> man xinput then
[05:13] <emma> okay
[05:13] <tjaalton> you can change those settings while the session is running.. that was not possible before
[05:15] <emma> i may stand a chance of figuring it out but not tonight i have to sleep now. after midight here.
[05:15] <emma> thanks for the clues. 
[05:15] <tjaalton> sure, np
[05:17] <bryce> heya tjaalton
[05:18] <tjaalton> hi bryce
[05:33] <tjaalton> bryce: the autotoolized mesa doesn't build intel DRI drivers for lpia, but is i915_dri.so the only one needed there?
[05:34] <tjaalton> I think it is
[05:34] <tjaalton> I've got also some xkb-data fixes on the radar before a6
[05:37] <bryce> cool
[05:37] <bryce> did the autotoolized mesa build them before?
[05:38] <bryce> I don't remember that -psb required them, and I don't know if there's any other gfx hw on lpia that uses -intel.  maybe...
[05:42] <tjaalton> there's bug 270106
[05:43] <tjaalton> so while the DRI driver is never really required, it does help with 3D :)
[05:43] <tjaalton> and it got dropped when the package was autotoolized
[05:44] <tjaalton> which was July'ish
[05:59] <bryce> hrm
[05:59] <bryce> any ideas why it got dropped?  would it be easy to add back in?
[06:14] <tjaalton> yes it is. it got dropped by accident, since the list of drivers to build varies based on the architecture
[06:15] <tjaalton> I've got it ready on my tree, but wanted to make sure i915 was enough
[06:21] <bryce> ah, yeah I believe so
[06:22] <bryce> i965 might be worth having
[06:37] <tjaalton> ok, I'll add that too
[17:44] <james_w> tseliot: hey, have you seen bug 270980
[17:45] <tseliot> james_w: let me have a look at it
[17:52] <tseliot> james_w: ok, I'll fix it, however when my patch is accepted the virtual resolution will be calculated by the C part, therefore this is a temporary fix
[17:53] <james_w> ah, ok.
[18:19] <tseliot> james_w: ok, I have fixed the problem
[18:19] <tseliot> how can I associate a commit with a bug?
[18:20] <tseliot> s/commit/revision/
[18:20] <james_w> tseliot: commit with "--fixes lp:12345"
[18:20] <james_w> if you have a changelog entry with "LP: #12345" then debcommit in Intrepid will do that for you
[18:21] <tseliot> yes, of course the changelog has such entry
[18:24] <tseliot> james_w, bryce: the fix is in this branch: ~albertomilone/screen-resolution-extra/intrepid
[18:27] <tseliot> bryce: can you upload it for me (when you have the time), please?
[18:27] <james_w> tseliot: I don't see how the new code is any different, what am I missing?
[18:29] <tseliot> james_w: I made it look exactly as the C code
[18:29] <tseliot> and it works well here
[18:30] <tseliot> I have tested the function and passed it some values in a tuple as the real program would do
[18:30] <tseliot> and it works well
[18:31] <james_w> ok
[18:31] <james_w> the same tests show the old version was broken?
[18:34] <tseliot> wait, no, now they don't
[18:34]  * tseliot wonders what happened before...
[18:35] <tseliot> james_w: this makes little sense
[18:35] <bryce> tseliot: we're in freeze for alpha6 starting today
[18:35] <tseliot> the C part is ok
[18:35] <tseliot> bryce: ok, no problem
[18:36] <james_w> tseliot: is it whatever passes the values that is wrong then?
[18:38] <tseliot> james_w: the C program passes those values and that part looks good
[18:40] <tseliot> james_w: are we sure that the user chose the right settings?
[18:40] <tseliot> it has always worked for me here and it worked for bryce too
[18:40] <james_w> tseliot: I'm not sure, I have no prior experience with "Virtual" to know what the correct values are
[18:41] <james_w> he does say that changing it gave him a working set up
[18:41] <tseliot> yes, and he's right
[18:42] <james_w> I can't test at the moment due to other bugs, sorry
[18:42] <tseliot> no, problem, I'm too tired to do anything else too
[18:44] <james_w> for param in params[0]:
[18:44] <james_w> should that not be
[18:44] <james_w> for param in params:
[18:44] <james_w> so that it considers all of sys.argv
[18:45] <james_w> that will only look at the first, and so could lead to taking max(first) -> first
[18:45] <james_w> so if the second is larger it won't get considered
[18:46] <james_w> ah, def computeVirtual(*params):
[18:46] <tseliot> yes
[18:48] <james_w> so it get's called like "1024x768:0,0 1280x968:1024,0"
[18:49] <tseliot> 0,0:1680x1050 0,0:1600x1200
[18:49] <james_w> no, other way round
[18:49] <james_w> yeah
[18:49] <tseliot> xposition, yposition, width, height
[18:50] <tseliot> xposition, yposition:widthxheight
[18:50] <tseliot> this one looks better ^
[18:50] <tseliot> so in your example
[18:51] <tseliot> the x position of the 2nd screen will be 1024
[18:51] <tseliot> and you will have to add the x position to the width
[18:51] <tseliot> and get the highest value
[18:52] <Ng> tjaalton: bug 262605 wouldn't be related to seeing mieqEnequeue errors and X getting wedged, right?
[18:52] <Ng> I just unlocked the screensaver and was left with just my backdrop and a mouse pointer. sshing in showed a lot of these in X logs:
[18:52] <Ng> [mi] mieqEnequeue: out-of-order valuator event; dropping.
[18:52] <Ng> [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[18:52] <jcristau> Ng: seeing mieqEnqueue errors is a symptom of X getting wedged
[18:52] <jcristau> or, the gpu locking up
[18:53] <jcristau> so that alone doesn't say anything about the cause
[18:54] <Ng> there's nothing of note in syslog
[18:54] <Ng> and the Xorg.0.log just goes from EDID output straight into those messages
[18:55] <james_w> tseliot: yeah, I can't see what's wrong here
[18:58] <tseliot> james_w: I have asked that user to try again, just to be sure
[18:58] <james_w> thanks
[18:59] <tseliot> james_w: thanks for reporting. BTW I subscribed to the bugs of that package.
[18:59]  * tseliot > dinner. Bbl
[19:00] <Ng> jcristau: if it happens again, is there anything I can do to get some more useful information?
[19:02] <jcristau> Ng: see where X is blocked (gdb helps)
[19:03] <jcristau> also if it's reproducible it's easier
[19:18] <superm1> bryce, at some point you had a document that referred to setting up faulty keymappings, but i seem to forget where I saw it.  you have a link handy?
[19:18] <bryce> probably http://wiki.ubuntu.com/X/Troubleshooting - the keyboard section
[19:21] <superm1> ah yup.  i'll see if this can help get a few missing keycodes sorted out on the latitude xt
[19:21] <superm1> thanks
[19:37] <superm1> it looks like there is no hotkey defined in input.h to trigger a screen rotation is there?
[23:19] <Ng> bryce: OOI, any ideas what intel's plans are for video acceleration?
[23:20] <bryce> what's OOI mean?  or are you spewing binary at me?  ;-)
[23:21] <bryce> Ng: for acceleration, have you looked at UXA?
[23:21] <Ng> Out Of Interest
[23:21] <Ng> I've not looked at anything specifically
[23:22] <Ng> I'm just curious about video acceleration, because I tried to play a 1080p video earlier on and it sucked
[23:22] <Ng> (on a G45)
[23:24] <bryce> yeah I think the priority is going to be to get the GEM/UXA stuff worked out first
[23:25] <bryce> see http://ph.ubuntuforums.com/showthread.php?t=890843
[23:52] <Ng> bryce: that stuff is more about 2D acceleration though, right?
[23:52] <bryce> it involves both 2d and 3d
[23:52] <Ng> I'm thinking more like xvmc
[23:53] <Ng> basically I think a G45 and a Core2Duo 6300 ought to be able to play 1080p H.264 :)
[23:53] <Ng> mplayer was close to being able to, with a single thread eating all the CPU and using Xv, so pretty much just using the CPU since no scaling is required
[23:58] <Ng> jcristau: ok. so far it's not reproducible, but next time I will ssh in and fire up gdb