[06:46] trying to get a marblemouse working on intrepid (upgraded from hardy) [06:46] two problems [06:46] first is the button reassignmentL: [06:46] njh@thestral:~/svn/lib2geom$ xinput set-button-map 6 1 8 3 4 5 6 7 2 9 [06:46] X Error of failed request: BadValue (integer parameter out of range for operation) [06:46] Major opcode of failed request: 148 (XInputExtension) [06:46] Minor opcode of failed request: 29 (X_SetDeviceButtonMapping) [06:46] Value in failed request: 0xa [06:46] Serial number of failed request: 13 [06:46] Current serial number in output stream: 13 [06:47] the second is that although the scroll button correctly disconnects the cursor movement, it doesn't generate any scroll events [06:47] here's my props: [06:47] Device 'Logitech USB Trackball': [06:47] Device Enabled: 1 [06:47] Middle Button Emulation: 1 [06:47] Middle Button Timeout: 50 [06:47] Wheel Emulation Inertia: 10 [06:47] Wheel Emulation: 1 [06:47] Wheel Emulation X Axis: 6, 7 [06:47] Wheel Emulation Y Axis: 4, 5 [06:47] Wheel Emulation Timeout: 200 [06:47] Wheel Emulation Button: 9 [06:47] Drag Lock Buttons: 0 [06:47] these settings work on intrepid from scratch [06:48] njh: Please don't flood. The xinput problem is probably caused by your failing to understand that it wants a permutation of the buttons. [06:49] I gave it permutation of the buttons [06:49] There are precisely 9 buttons that X knows about? [06:49] how would I find out? [06:49] as I said, the same settings worked on a different machine [06:50] it's hard to debug this when debuging information is scant and the documentation lacking [06:50] It depends on the mouse, not the machine. [06:50] it is the same mouse [06:50] I simply unplugged it from one and moved it to the other [06:50] Are you sure you're giving it the right device ID? [06:50] but I'll just try again [06:50] yes [06:52] yep, it still works [06:53] so same mouse, both intrepid, same options [06:53] works fine on machine A (installed from CD) [06:53] doesn't on machine B (upgrade from vanilla hardy) [06:53] Same architecture? [06:54] No input devices in xorg.conf? [06:54] both 32 bit x86 [06:54] all input devices commented out ("commented out by update-manager, HAL is now used") [06:55] 'xinput list' from both machines. [06:55] !pastebin [06:55] pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) [06:55] *sniff* how primitive [06:56] Hm? [06:57] can't copy and paste over remote desktop it seems :( [07:01] and now it works [07:01] oh well, bug solved [07:01] Heh. [07:01] though I wish I could make the hal thing work [07:01] What do you mean? [07:01] rather than using xinput [07:02] What isn't working about it? [07:02] I followed the instrutions at: [07:02] https://help.ubuntu.com/community/Logitech_Marblemouse_USB [07:02] but the fdi match file doesn't [07:02] Which bit doesn't work? Just the buttonmapping? [07:03] so I just created a new file.fdi with that xml [07:03] Oh. [07:03] That would do it. [07:03] That's not complete. [07:03] * wgrant fixes. [07:04] Add: [07:04] [07:04] [07:04] To the start. [07:04] And: [07:04] [07:04] [07:04] incidently, any reason why that file isn't included in intrepid itself? [07:04] to the end. [07:04] Nobody I know has that hardware, and I wasnt sure if that was appropriate for the ubiquitous configuration. [07:05] ah, well everyone I mentioned I'd bought it too said they also had one [07:05] I hadn't heard of it until I tried to fix that page. [07:05] does it hurt to have such stuff? [07:05] Does everybody use the trackball like that? [07:05] given that it's 545 bytes [07:05] pretty much [07:06] it's the way that windows does it [07:06] ok, I've updated the fdi file [07:06] OK. [07:06] do I just unplug and replut? [07:06] That should do it, yes. [07:06] nup [07:06] where does the errors go? [07:06] Hmmm. [07:07] You could check /var/log/Xorg.0.log [07:07] It's possible that you'll need to restart hal (ie. reboot), but I've never had to. [07:08] it's finding the mouse, but setting the wrong options [07:08] Is it setting any of them? [07:09] yes, but to the hard defaults [07:09] You might want to try giving it the full button mapping - that might be why people have said the given fdi file doesn't do that. [07:09] it's not setting anything atm [07:09] Hmmmmm. [07:09] should 1 8 3 2 9 be a permutation? [07:09] I suspect evdev will want it to be, yes. [07:10] (and if so, how do I find out the correct number of buttons) [07:10] mouse worked without it, but I'm not sure about evdev. [07:10] hmm [07:10] it hasn't set any of the other props though [07:10] which suggests that it isn't matching [07:10] Does lshal see that same product name? [07:11] yes [07:11] OK, you might have to restart hal. But don't do that while X is running. [07:11] no [07:11] that's bad [07:12] I wonder if adding that to the existing preferences file would work [07:12] It's possible that hal saw the file, noticed that it wasn't a real fdi file, so is now going to ignore it until you restart it. [07:12] wgrant: why not restart hal while X is running? [07:12] it buggers everything up [07:12] btdt [07:12] bryce: X has got very very angry with me because of that twice now. [07:12] X wanders away and dies eventually. [07:13] yeah, that [07:13] wgrant: interesting. I've been doing that without issue, although not recently [07:13] wgrant: is there a bug about that issue? [07:13] ok, so deviceinfo tag is once per file? [07:13] bryce: I didn't think it would count as a bug. [07:13] it's a bit bad I think [07:14] wgrant: no? One of the advertised features of all this hal stuff was that hal changes could be made without having to restart X. [07:14] njh: deviceinfo is the top-level element, so yes, only one. [07:14] bryce: I normally don't have to restart hal to make changes to the hal config. [07:14] nup [07:14] still no go [07:14] so it's probably not matching something exactly [07:14] I wish it would tell me why not [07:15] bryce: Let's see what X does if I restart hal now... maybe brb. [07:15] a hal reload option might be useful [07:15] Hm. [07:15] X survived that time. [07:15] It doesn't always. [07:15] no [07:16] it could be a heisenbug [07:16] huh. well, if either of you run into this issue again, please file a bug on it with the logs / error messages. That seems like something well worth getting fixed. [07:16] restarting hal didn't fix the problem in any case [07:16] troubleshooting input-hotplug issues are hard enough without also having X fall to pieces ;-) [07:16] bryce: Sure, will do. [07:17] yes [07:17] Yep... [07:18] the doco says match key="@blah" [07:19] njh: Try contains= rather than string= [07:20] nup [07:20] I wish I knew exactly what steps are required [07:21] do I need restart hal after every edit? [07:21] njh: I don't think so. I can just drop a new file in /etc/hal/fdi/policy, replug the device, and have the new setting in place. [07:21] I don't even know if it is reading the file :( [07:22] ok [07:22] is there something I could put in the file which would prove it is being read? [07:22] perhaps a syntax error... [07:22] nup, a syntax error does not break it :) [07:23] I don't know how hal works, sorryu. [07:23] -u [07:24] I was debugging by diffing lshal output before and after plugging in the device [07:24] That would work. [07:27] * wgrant just read the email on ubuntu-x about the tablet config UI. [07:27] All of those things look like they should be exposed through XI device props... [07:27] morning [07:27] > input.x11_options.ButtonMapping = '1 8 3 2 9' (string) [07:28] it's setting the buttons! [07:28] just nothing else [07:28] Morning tjaalton. [07:29] heya tjaalton [07:30] wgrant: yeah I'm writing a reply to that thread, it would be great to get your input on it as well [07:31] I'm wondering whether the x names differ from the xinput names [07:31] bryce: I think we're going to need one awfully big unified gnome-input-properties... [07:31] wgrant: well my hope is to try to keep the scope of what we do within reason [07:32] Of course. [07:35] ok, I've got it correctly matching the mouse [07:35] bryce: I was wondering, should we make it a policy that every change is in git, even the small ones. Then there would be no need to remove the Vcs-* stuff from control files like loïc did, and it would be more clear to the casual committer [07:35] njh: What needed changing? [07:35] [07:35] Ah, so it's a different name. [07:35] doesn't actually set the xinput props though [07:35] bryce: also, the mail address could probably be changed to ubuntu-x [07:35] but lshal sets props being defined [07:36] If hal sees them and the device has been replugged, X should see them too. [07:36] But the xinput/hal names won't match. [07:36] tjaalton: to be honest, I find doing things in git to be a real hassle, and makes things take 2-3 times as long as they should [07:36] I think the old xorg.conf names should die soon and hal should be able to tell the server to set XI props. [07:37] hal does not need a restart [07:37] ok [07:37] bryce: we should probably have a git BOF at UDS then :) [07:37] I've been removing the spaces from the prop names [07:37] bzr! [07:37] bzr can't do git [07:37] is that bad? [07:38] njh: xinput properties don't have the same names. You should use fdi files as if they were xorg.conf. [07:38] oh [07:38] I have no idea what the xorg names are [07:38] I'd be willing to give it a go with bzr [07:38] njh: The names in the example look good. [07:38] bzr makes sense, but the problem is that it's not trivial to keep pulling from git. [07:39] Importing from git is easy, but not continously. [07:40] hm, I've tried doing merges through git a few times, but I found the procedure to be fairly intricate [07:40] having stuff in git.d.o allows the debian people to see what we do, and point out potential problems like jcristau does [07:40] for complex things like xserver, xorg, etc. that have a lot of patches and changes to merge, I can accept that it's worth the trouble, but with packages that have fewer changes it seems quicker just to do merges by hand [07:41] wgrant, but they don't work :) [07:41] so I can now effectively set hal attributes [07:41] but I can't work out how to convince myself that X is listening to them [07:41] bryce's diff trick is very helpful [07:41] add that to your toolbox! [07:41] git fetch; git merge debian-unstable, that's not difficult [07:42] I find git frustrating [07:42] despite mental's badgering, I still find myself using svn [07:42] when your own tree is old, you need to git rebase origin/ubuntu first [07:42] there's at least one mesa change that is not in git yet [07:42] I suspect it's just curmudgeonness [07:43] it took me years to switch from cvs :) [07:43] at least with git I can use both on the same project [07:43] git doesn't seem to make sense. [07:43] bzr is fine. [07:43] svn doesn't make sense :) [07:43] it must [07:43] it was written by god himself [07:43] well I find bzr confusing so here we go :) [07:44] mental dislikes bzr [07:45] nup [07:45] those parameters are not being fed through to X [07:45] they get as far as hal [07:46] njh, now that he works for canonical and will probably have to use it, it'll be interesting to see if his opinion evolves [07:46] actually, he hates it _since_ he started using it at canonical [07:46] on the other hand, he has seen the light wrt python :) [07:46] Who are we talking about? [07:46] * njh smugly points out that bryce now uses apt and mental now uses python [07:47] wgrant, nobody knows... [07:47] wgrant: njh and mental are two of the guys that founded Inkscape with me [07:47] he is known as.... [07:47] ...mental [07:47] Ahh. [07:48] yes, the triumvirate: the maiden, the mother and the crone [07:48] (we're still fighting over who is what) [07:48] njh: fwiw, I'm finally doing python too [07:48] bryce, good to hear [07:49] glad you've finally seen the light [07:49] How can one not do Python? [07:49] bryce and I used to argue about python vs perl [07:50] so, does anyone else have evidence that setting parameters via fdi actually has any effect on xorg? [07:50] wouldn't go so far as seeing light... [07:50] because I can make them anything, and nothing changes [07:50] njh: Yes. I do it all the time. [07:50] the data is coming from somewhere else [07:50] njh: It depends on whether the driver is looking at them or not. [07:51] so what is ZAxis? [07:51] is it the same as YAxis? [07:51] is there an XAxis? [07:54] meh, I'm tired [07:54] thanks for all your hel[ [07:54] help [07:54] at least I can trust hal works [07:54] I just need to connect it to xorg [07:55] however, unless you have evidence to the contrary, this page is wrong: [07:55] https://help.ubuntu.com/community/Logitech_Marblemouse_USB [07:55] perhaps you can ask if anyone has actually got it working [07:57] looks like people are still having trouble anyway [07:57] I've seen a few people on ubuntuforums use that fine,. [07:57] * njh reads more bugs [07:57] really? (does spoke eyebrow thing) [07:58] or merely run away [07:59] ok, bed time [07:59] ttyl [09:03] mvo: hey, I've seen a lot of "failed to install/upgrade" errors due to "package foo is already installed and configured". what's causing that? [09:06] I was going to ask that too ;-) [09:08] they are all over the place, so it's pretty common I guess.. [09:08] tjaalton: do you have a example bug number for me? [09:09] mvo: bug #296576 [09:09] Launchpad bug 296576 in eog "package eog 2.24.1-0ubuntu1 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/296576 [09:09] mvo: bug 296571 (just happened to look at ghostscript bugs) [09:09] Launchpad bug 296571 in ghostscript "package ghostscript 8.63.dfsg.1-0ubuntu6 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/296571 [09:09] plenty of them against the x packages too [09:09] thanks, looking [09:11] seb128: heh, appears to be the same reporter [09:11] he likely opened several duplicates [09:12] yep [09:30] heya mvo [09:31] hm, so I read reports that compiz does hang on a i945 for intrepid --- lp#? [09:31] tjaalton: is there someone familiar with intel I could talk to? do we have a contact at intel? I mean, blacklisting i830,845,945 does not leave that many cards that we don't blacklist [09:31] bryce: ^--- ? [09:32] bryce: good monring [09:32] bryce: https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/296819 [09:32] Launchpad bug 296819 in compiz "Intrepid Compiz hangs on login for i945GM video cards" [Undecided,Incomplete] [09:32] mvo: i830/i845 should be considered separate from i945 [09:32] bryce: it seems like it is ot affecting all i945 system so it is less servere [09:33] bryce: 830/845 are blacklisted now [09:33] but blacklisting i945 would blakclist half of the laptops out there (and all netbooks ;) [09:33] pre-855 is hardly supported by upstream any longer, so compiz issues on those chips are not terribly high priority (unfortunately IMHO, but seems reality) [09:33] i945 are more recent and more important [09:34] yes, I'm sad about the lack of <855 [09:36] from bug reports, I've seen huge variability in i945 [09:36] many issues are specific down to the subsystem vendor pci id [09:41] ...so if you blacklist, I'd just ask that you blacklist at the subsystem vendor pci id. (i.e., the second line from lspci -vvnn) [09:41] pitti had the same pci id and works fine [10:01] if two people with the same subsystem vendor pci id have the same problem, then one would have to conclude it's due to some difference other than video card chips. [10:01] anyway, night. [10:01] night [10:01] night [10:02] mvo: did you look at this install bug? [10:03] seb128: no, was doing other stuff [10:03] not yet [10:03] ok [17:52] tseliot, not sure if you were aware yet: http://www.nvidia.com/object/linux_display_ia32_177.82.html [17:52] it's a bug fix release [17:52] superm1: no, I wasn't aware of that. Thanks [17:53] tseliot, when they are saying mobile GPUs with suspend problem, it's most 9xxx mobile GPUs, and rather annoying :( [17:54] superm1: ok, I'll request another SRU soon [17:55] tseliot, if you need sponsorship to jaunty, let me know and i can upload it when you've got packaging ready [17:55] ok ;) [17:55] tseliot, or if you normally use PPA pocket copying, nvm [17:56] I usually upload the source to my webspace [20:17] will there be any trouble if I buy a HDCP-aware monitor for use with Linux? [20:26] solarion: no [20:28] tjaalton: thanks. I waited and then asked xorg-devel. :) [20:29] yeah noticed that afterwards [20:30] :) [20:30] what'd you say are the most important things to consider in an lcd monitor? [20:30] screen size and res are obvious [20:39] dont buy the cheapest, and preferably with !TN panel [20:42] why not the cheapest? [20:44] there's a reason they are cheap [20:46] brightness is another consideration [20:46] although most lcd's these days are sufficiently bright [20:46] what's a good brightness? [20:47] just make sure it's got a broad range [20:48] tjaalton: I mean, is there usually a specific thing cheap lcd monitors are cheap because of, that's not immediately obvious to the novice? [20:49] missing digital input(s), TN panels, bad ergonomics etc [20:49] what digital inputs would be missing? [20:50] dvi for instance [20:51] aside from DVI and VGA, what other connectors do you think are important (HDMI is irrelevant to me, I think) [20:54] mine has a usb-hub in it which is handy [20:55] * solarion ponders [21:06] what is better than a TN panel? [21:09] IPS/*VA [21:09] eizos are MVA's I think.. [21:33] why is tn bad? [21:48] the viewing angle and gamut coverage is narrower [21:48] ah [21:49] what's the going price for a good lcd? [21:49] but just buy what pleases your eyes and budget :) [21:49] I can buy a second card and 3 monitors for under $600. :) [21:49] good resolution too [21:50] my 24" benq cost around 800EUR, and it's pretty good [21:50] ouch [21:50] that's probably more than the bosses would let me have. :) [21:50] yes, you can do a lot of stuff for $600 ;) [21:52] hm s/do/get/ [21:54] both work. :) [21:54] thanks for the info [21:54] maybe when I'm a professor I can get a real LCD. [21:55] heh, and some time I'll get an eizo for photo management :) [21:58] wow, 24" review champ eizo for 500EUR [22:00] hi [22:01] i'm trying to test GEM with 2.6.28-rc4 and xorg/mesa/intel master branches. I'm getting in xorg log (II) AIGLX: Screen 0 is not DRI2 capable [22:01] but 3d works. so i'm wondering this DRI2 issue. any idea? [22:02] don't think anyone here has gone that far [22:02] besides it's not the master branches you want [22:02] i'm not able to find any info how to check if GEM is actually used if you understand :) [22:02] there's no dri2 support in intel ddx master [22:02] so that's expected [22:03] so thats explain it. exist some dri2 branch is it worth of try? [22:04] i don't think it's worth it at this point [22:06] i though that new 2.5.0 with gem and uxa has dri2 === superm1` is now known as superm1 [22:15] nope === philwyett_ is now known as philwyett [22:42] tjaalton: regarding bug 278318, I've updated the patch to flip it such that texturedvideo is true by default. I'll post a debdiff. [22:42] Launchpad bug 278318 in xserver-xorg-video-intel "video tearing with textured video on intel card" [High,Triaged] https://launchpad.net/bugs/278318 [22:48] tjaalton: posted. If people wish for something more elaborate than just that, then I think we should leave it to jaunty and skip doing an sru. [22:49] restoring an xorg.conf option seems pretty low risk, but mucking about in the video driver logic is probably better to leave for the development branch.