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