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