[00:56] <bdmurray> bryce: did you see the updates to bug 248521?
[00:56] <ubottu> Launchpad bug 248521 in xserver-xorg-input-vmmouse "vmmouse seems to register incorrect x,y values for mouseclick" [High,Fix released] https://launchpad.net/bugs/248521
[00:58] <bryce> thanks
[01:00] <bryce> bdmurray: hrm
[01:00] <bryce> I knew I should have asked him to give a debdiff...
[01:01] <bryce> bdmurray: ok reopening bug
[01:01] <bdmurray> thanks
[01:16] <bryce> tjaalton: I guess I don't know what you mean with your comment on my patch for 261977
[01:17] <bryce> tjaalton: if execution reaches my section of code, it's already gone through trying to use the .ids files, so not really sure what you mean.
[02:26] <bryce> heya federico1
[02:27] <bryce> bdmurray: uploaded
[02:37] <federico1> yo bryce
[05:44] <tjaalton> bryce: hmm, I realize that it shouldn't be a problem after all, since we use the .ids files
[05:44] <tjaalton> but otherwise it would be, since matches[0] would be occupied before it reaches the vendor-id -based autoconfigure
[06:03] <bryce> heya tjaalton
[06:04] <bryce> tjaalton: well perhaps I misunderstood your original description of the problem, because I understood that having maches[0] be occupied was exactly the intent?
[06:06] <bryce> tjaalton: I assume that if you are not using an xorg.conf, that it would go through the .ids files to detect the driver to use, and only if no .ids files match, would it use -vesa
[07:21] <tjaalton> bryce: yes, you understood me correctly, and I misunderstood the implications of the patch :)
[07:22] <tjaalton> in other words, we should be covered because we have the .ids files
[07:22] <bryce> ah ok
[07:22] <tjaalton> I just forgot that yesterday
[07:23] <bryce> has anyone tested the patch so far?
[07:23] <tjaalton> I haven't tested it yet, but will do so ASAP
[07:23] <tjaalton> mm, what's that smell..
[07:24]  * tjaalton goes to the shower
[08:10] <tjaalton> superm1: ping? you have an opinion on bug 282203?
[08:10] <ubottu> Launchpad bug 282203 in wacom-tools "Wacom tablet hotplug is no longer enabled by default" [Wishlist,Triaged] https://launchpad.net/bugs/282203
[08:10] <tjaalton> I'm having second thoughts
[08:12] <tjaalton> superm1: and since you added the N-Trig to the fdi-file, I think you'd like to keep the hotplug working, even if it's not fully working and would need more work to get it to work locally
[08:21] <tjaalton> sigh, I'm done with joysticks for now
[08:24] <bryce> yeah, those guys have also been sending me email directly
[08:24] <bryce> I just referred them back to your comments on the bug
[08:24] <tjaalton> I should probably play games more
[08:25] <bryce> we went through the same situation with video back a few releases ago when xrandr came in
[08:25] <tjaalton> happy living on the edge
[08:25] <bryce> there are some problems that just require going through breakage for a release or so before it restabilizes and so the original issue finally goes away
[08:26] <bryce> although of course we *still* can't do triple-head, like could be done in feisty, but....
[08:26] <tjaalton> "stick to hardy" is my next reply
[08:28] <bryce> or "send a patch"
[08:28] <tjaalton> heh, yeah those things need more work on the foundations, and AIUI things are coming together now that the memorymanager is finally in 2.6.28rc
[08:31] <bryce> really, intrepid is intended to push envelopes a bit
[08:33] <tjaalton> I think we are doing well in that regard
[08:33] <tjaalton> :P
[08:34] <bryce> well, it's definitely something I thought about early on, after the xrandr experience
[08:34] <bryce> we could have held off one more release before adopting input-hotplug
[08:34] <bryce> and then in theory upstream would have independently solved issues with various input devices and such
[08:35] <tjaalton> I think we've helped upstream with this, like the crasher with joysticks
[08:35] <bryce> yep
[08:35] <bryce> also, we'd have had to go through some amount of pain regardless, whenever we adopted it
[08:35] <bryce> intrepid is a good point, because it's right on the heels of an LTS
[08:36] <bryce> so for business type users, end users, and others who can't handle some instability, hardy is still right there on hand
[08:36] <bryce> but for developers, power users, and others who want to see the latest and greatest stuff, this is useful
[08:37] <bryce> I'm glad it's joysticks and wacoms we're worried about, and not keyboards and mice
[08:40] <tjaalton> yeah
[09:05] <wgrant> Lots of people are complaining at the breakage.
[09:05] <tjaalton> wgrant: joystick?
[09:05] <wgrant> tjaalton: And input config and the like.
[09:05] <wgrant> But they eventually shut up after a bit of an argument about how we need to break things due to bad timing sometimes.
[09:07] <tjaalton> well, pitti replied to the thread, and if hal can be fixed to handle joysticks properly, then this issue is easy to fix
[09:07] <tjaalton> but sure, that's not all
[09:09] <wgrant> tjaalton: I checked HAL specs last night, and input.joystick is already defined.
[09:09] <wgrant> It's just not used, at least in Ubuntu.
[09:10] <tjaalton> right
[09:10]  * wgrant sighs.
[09:10] <tjaalton> hald/linux/device.c probably needs fixing
[09:10] <wgrant> How does my university manage to get their 2009 reenrolment form to not work in Firefox 3?
[09:10] <wgrant> I'm sure at least 90% of the student population uses Firefox 3.
[09:11] <tjaalton> what, it already checks for joysticks
[09:11] <wgrant> And it's a basic POST form, but the Java server manages to crash.
[09:11] <wgrant> tjaalton: Does it!?
[09:11] <tjaalton> check the file
[09:11] <wgrant> I didn't see that last night.
[09:11] <tjaalton> hal source
[09:11] <wgrant> I glanced over it a bit.
[09:12] <tjaalton> I should also write a 30min presentation about Ubuntu for Thursday, but oh well, RC coming up
[09:12] <wgrant> I agree with the TODO...
[09:12] <wgrant> That check looks about as arbitrary as one can get.
[09:13] <wgrant> And why does a joystick become a tablet as well in that case?
[09:13] <wgrant> What a strange piece of code.
[09:14] <tjaalton> heh
[09:15] <bryce> night
[09:15] <tjaalton> night bryce
[09:15] <wgrant> Night bryce.
[09:45] <tjaalton> yep, the patch for bug 261977 works fine
[09:45] <ubottu> Launchpad bug 261977 in dell "nv is chosen even if it doesn't support the card" [Undecided,Confirmed] https://launchpad.net/bugs/261977
[10:27] <jcristau> tjaalton: vesa as fallback is only ok on x86 afaik. but i guess ubuntu only ships those so.. :)
[10:28] <tjaalton> jcristau: right..
[10:28] <tjaalton> jcristau: well, the fallbacks could be added still
[10:28] <tjaalton> fbdev I mean
[10:28] <tjaalton> ppc is busted anyway :)
[10:29] <jcristau> yeah what's up with that?
[10:30] <tjaalton> no news, but it's not the xkb patches
[10:30] <tjaalton> actually, dan did update the bug (bug 281610
[10:30] <tjaalton> )
[10:30] <ubottu> Launchpad bug 281610 in ubuntu-ps3-port "[regression, intrepid] Xorg servers broken "No core keyboard" and "failed to initialize core devices"" [Critical,In progress] https://launchpad.net/bugs/281610
[10:49] <jcristau> tjaalton: i suspect the casts in DeviceSetProperty() could break things
[10:50] <jcristau> because endianness
[10:50] <tjaalton> hmm
[10:50] <tjaalton> yeah somehow I don't think 1.5.2 is to blame..
[10:50] <jcristau> DisableDevice(inputInfo.keyboard) -> fail
[10:50] <jcristau> or something like that
[10:52] <jcristau> hmm
[10:53] <jcristau> that said dev->enabled is a Bool, so maybe not
[10:53] <jcristau> in any case investigating that might help
[11:07] <tjaalton> ok, I'll have a look
[12:15]  * albert23 thinks he found a bug in xxi-evdev that causes the joystick problem in intrepid
[12:15] <albert23> #define TestBit(bit, array) (array[(bit) / LONG_BITS]) & (1 << ((bit) % LONG_BITS)) seems to be wrong
[12:16] <albert23> it must be: #define TestBit(bit, array) (array[(bit) / LONG_BITS]) & (1l << ((bit) % LONG_BITS))
[12:16] <albert23> I found my gamepad claimed to have button 287, which does not really exist
[12:17] <albert23> Then I tested the TestBit macro, and found it returned values not equal to 2^31 for Testbit(287, key_bitmask)
[12:18] <albert23> So I made the above change in evdev.c, and now evdev no longer manages the gamepad.
[12:48] <jcristau> albert23: care to file this on bugs.freedesktop.org?
[12:51] <albert23> jcristau: I can do that. Is that for product xserver?
[12:52] <jcristau> albert23: product xorg, component Input/evdev
[12:52] <albert23> jcristau: OK
[12:52] <jcristau> thanks
[13:14] <albert23> jcristau: https://bugs.freedesktop.org/show_bug.cgi?id=18150
[13:14] <ubottu> Freedesktop bug 18150 in Input/evdev "evdev detects non-existing button as mouse button" [Normal,New] 
[13:22] <tjaalton> albert23: thanks, that's probably why it doesn't manage my rumblepad on i386, which is correct
[13:22] <tjaalton> um, I mean that it worked on 32bit
[13:23] <tjaalton> ..platforms
[13:23] <jcristau> that would explain the difference persia was getting between 32 and 64bits
[13:23] <albert23> I got the same difference between i386 and amd64
[13:24] <jcristau> i'll apply the fix upstream tonight if nobody beats me to it
[13:24] <tjaalton> hum, need to get that account :)
[13:33] <tjaalton> that patch alone should have been enough then to fix the crasher
[13:39] <tjaalton> albert23: so, with this patch you can use /dev/input/js* normally?
[13:39] <albert23> tjaalton: Yes indeed. jscalibrator says it uses that device and works fine
[13:40] <tjaalton> albert23: win :)
[13:42] <tjaalton> oh right, you mentioned that on b.fd.o
[15:37] <tjaalton> hm, could the strncpy's be replaced by xnfstrdup..
[16:08] <superm1> tjaalton, ideally yeah i'd like to keep it working, but it's not critical.  it was more of something nice to do
[16:09] <tjaalton> superm1: yep, it'll be back after RC
[17:26] <tjaalton> wacom-tools, evdev uploaded, post RC
[17:31] <bryce> morning
[17:32] <tjaalton> morning bryce.. looks like a number of bugs got resolved today :)
[17:33] <bryce> wow
[17:33] <tjaalton> the joystick issue should be close to being fixed
[17:33] <bryce> great, yeah I was going through old bugs last night closing them too
[17:34] <tjaalton> albert23 found out that the problem was on amd64 only, and a one liner made evdev to reject joysticks like on 32bit
[17:34] <tjaalton> and mjg59 posted a patch for hal to use input.joystick, so x-x-i-j should be easy to fix use that
[17:35] <tjaalton> bryce: the patch for "nv chosen.."; it used strncpy's, what about using xnfsrtdup like with the fallback drivers?
[17:36] <tjaalton> then you wouldn't need to check for the memory
[17:37] <tjaalton> and it should check for at least __powerpc__ and use fbdev there
[17:38] <tjaalton> it got the green light, will get in post-RC
[17:41] <bryce> tjaalton: sure I can make that change
[17:42] <tjaalton> would make it shorter as well :)
[17:43] <tjaalton> it's pushed to git.d.o btw
[17:43] <bryce> oh?  link?
[17:43] <tjaalton> git fetch?-)
[17:44] <tjaalton> & rebase origin/ubuntu
[17:44] <bryce> oh, I thought you meant it was taken upstream
[17:44] <tjaalton> ah, no
[17:46] <mnemo> bryce: i've been trying to get this patch cherry picked into intrepid (so that G45 machines dont freeze xorg on startup) --> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/285572
[17:47] <ubottu> Launchpad bug 285572 in linux-meta "X freezes right after login when using EXA on G45 machine" [Undecided,New] 
[17:47] <mnemo> do you know if it's a lost cause of can stuff still be fixed?
[17:47] <mnemo> i dont want to waste time trying to convince people if there is some rule saying stuff can never be merged later than this or that deadline etc
[17:49] <tjaalton> yeah, radeonhd deathmatch on xorg@
[17:49] <tjaalton> mnemo: it could be done post-release
[17:50] <tjaalton> vesa should work on the livecd
[17:51] <superm1> tjaalton, the nv thing is slipping as a post-rc?
[17:51] <tjaalton> superm1: yeah..
[17:51] <superm1> tjaalton, <shrug>....
[17:52] <tjaalton> superm1: but it works, I tested it with various ways
[17:52] <superm1> tjaalton, is there any way/thing that i'd be able to do to help it for going in at RC? 
[17:53] <tjaalton> superm1: bug pitti/slangasek?-)
[17:53] <bryce> yeah xnfstrdup cuts out some lines, nice
[17:53] <superm1> tjaalton, it's been blocking testing on at least 2 laptops for us from vendors not technically inclined enough to know how to handle the problem and work around it :(
[17:53] <tjaalton> bryce: good
[17:54] <tjaalton> superm1: yeah, should've tried it yesterday but there simply was no time ./
[17:54] <tjaalton> :/
[17:55] <tjaalton> now the only remaining bug that is IMO serious is the one with properties breaking input devices on big-endian platforms..
[17:57] <superm1> what architectures are supported that are big endian?
[17:57] <superm1> I thought i386 and amd64 were both little endian
[17:57] <tjaalton> right, none :)
[17:58] <tjaalton> but ps3-owners will be/are pissed
[17:58] <superm1> oh I thought powerpc supported both little endian and big endian
[17:59] <tjaalton> well, it's broken there anyway
[18:00] <tjaalton> but jcristau pointed out that it's likely DeviceSetProperty() that fails, and as a result disables the device
[18:01] <bryce> tjaalton: ok, fixed up the patch and pushed
[18:01] <bryce> tjaalton: I also added the non-vesa fallbacks for sun, &tc.
[18:01] <bryce> erf, wait
[18:01]  * bryce fusses with git
[18:01] <bryce> ok in now
[18:03] <tjaalton> bryce: great
[18:15] <bryce> if you wouldn't mind running one more test?  then I can upload, unless you're waiting on anything else?
[18:17] <tjaalton> no it's fine, I'll rebuild it
[18:18] <bryce> ok cool
[18:34] <mnemo> bryce: are you willing to push the xf86-intel patch for G45 if I find someone who will push the agp kernel patch? still talking about this bug (keith packard replied now and recommended we cherry pick these patches) --> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/285572
[18:34] <ubottu> Launchpad bug 285572 in linux-meta "X freezes right after login when using EXA on G45 machine" [Undecided,New] 
[18:37] <bryce> mnemo: looking
[18:38] <mnemo> bryce: this will enable us to boot on the very latest intel motherboards (that started shipping in july 2008)
[18:41] <bryce> mnemo: fdo not responding; can you post the x driver patch to the bug tracker?
[18:42] <jcristau> bryce: http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-intel.git;a=commitdiff;h=8971411781c5bd0b9e9d4c2c776ba6e21c313f00
[18:43] <bryce> aha thanks
[18:44] <bryce> mnemo: yes I'd be willing to push that patch
[18:45] <mnemo> great then I will try to find someone who can push the kernel part
[19:08] <mnemo> bryce: it seems that Amit Kucheria is willing to take the patch for intrepid
[19:13] <mnemo> bryce: can you take it from here or do you need me to do something else for this to happen?
[19:17] <mnemo> actually
[19:17] <mnemo> [20:17] <amitk> mnemo: patch is in. Go after bryce.
[19:18] <mnemo> bryce: please merge the xf86 part now
[19:24] <bryce> mnemo: on it
[19:27] <tjaalton> oh, the joystick fix was rejected for release
[19:40] <bryce> tjaalton: :-/
[19:40] <bryce> mnemo: will this close 272157?
[19:40] <bryce> (trying to figure out which lp# to attach the fix to)
[19:41] <bryce> (I mean, besides 285572)
[19:45] <mnemo> ive not tested with that particular motherboard but I think its highly likely
[19:46] <bryce> well, I'll use 285572 and ask the other bug to re-test after it's uploaded
[19:47] <mnemo> this is the same bug for my motherboard
[19:47] <mnemo> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/285572
[19:47] <ubottu> Launchpad bug 285572 in xserver-xorg-video-intel "X freezes right after login when using EXA on G45 machine" [High,Triaged] 
[19:47] <mnemo> ah yeah thats the one you mentioned :)
[19:47] <bryce> building, then I'll upload
[19:50] <bryce> mnemo: uploaded
[19:51] <tjaalton> bryce: well, it's ok as an SRU
[19:55] <mnemo> bryce: so tomorrow both the kernel fix and the xf86intel fix should be included in the daily ISO? --> http://cdimage.ubuntu.com/daily-live/current/ 
[19:55] <tjaalton> mnemo: likely after the RC
[19:56] <mnemo> ok
[19:57] <mnemo> i will test it asap and report back results on the relevant bugs in lp
[20:07] <bryce> great
[20:07] <bryce> tjaalton: need my help with the sru?
[20:08] <bryce> ok I got to run a friend to the train station; be back after lunch
[20:35] <federico1> tseliot: pingety ping
[20:36] <tseliot> federico1: hi
[20:37] <federico1> tseliot: I'm shaving a yak before I can look at your patches... I'm adding GError throughout the GnomeRR/GnomeRRConfig API, so that g-s-d and the capplet can at least present useful errors instead of failing silently
[20:37] <tseliot> federico1: what errors? The ones about the virtual resolution?
[20:38] <tseliot> or errors in general?
[20:41] <tseliot> federico1: BTW here you will find the patches that we have applied to the packages in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/275977
[20:41] <ubottu> Launchpad bug 275977 in gnome-control-center "Setting the Virtual resolution should be easier" [Wishlist,Fix released] 
[20:42] <tseliot> aah, you said GError, ok, forget my question then
[20:42] <federico1> tseliot: basically, I want callers of gnome_rr_* to know when the XRR functions return an error
[20:43] <federico1> or when Something Bad(tm) happens like not being able to read the config file
[20:43] <tseliot> federico1: yes, that would be nice
[20:46] <tseliot> federico1: BTW I'm writing python bindings for RandR with XCB so that all the functions available in gnome-desktop (included the ones to read EDID) are available in Python too
[20:47] <tseliot> federico1: now, back to the topic, let me know if you need a hand with either the GNOMERR stuff or with my patches
[21:16] <tjaalton> bryce: nah, it's pretty certain that it'll get in. just need to upload it to -proposed
[21:27] <tjaalton> bryce: ok, the xorg-server patch is now tested again, and works
[21:28] <tjaalton> night..
[21:29] <wgrant> tseliot: I've got input property stuff in my local python-xlib for testing purposes. Are you also adding it to python-xlib?
[21:31] <tseliot> wgrant: I was thinking of doing python-xcb-xinput
[21:31] <tseliot> but I have to finish python-xcb-randr first
[21:31] <wgrant> tseliot: How are you implementing it? Using ctypes directly on the libs?
[21:32] <wgrant> I see no python-xcb...
[21:32] <tseliot> wgrant: it's all python. I'm using xpyb
[21:32] <tseliot> which in turn requires the latest xcb-proto
[21:32] <wgrant> seb128: There's no package of xpyb?
[21:33] <seb128> wgrant: what is xpyb and why should I know? ;-)
[21:33] <tseliot> xpyb 1.0 was released last friday
[21:33] <wgrant> seb128: It means "I hate keyboards"
[21:33] <tseliot> hehe
[21:33] <seb128> buy a mouse? ;-)
[21:34] <tseliot> seb128: xpyb = python bindings for xcb
[21:34] <seb128> ah ok, still not the right guy now, I don't work on python or xcb
[21:34] <seb128> I'm a GNOME guy ;-)
[21:35] <tseliot> wgrant: were you looking for Sebastian Heinlein?
[21:35] <tseliot> i.e. glatzor
[21:35] <wgrant> tseliot: No, I was looking for t and hit tab.
[21:35] <wgrant> But I hit s and tab instead.
[21:36] <wgrant> Sorry seb128.
[21:36] <tseliot> aah
[21:37] <tseliot> and no, there's no package of xpyb in ubuntu. Let's introduce it in time for Jaunty
[21:37] <jcristau> talking of xcb, if someone tells me how the hell i'm supposed to package the new xcbproto, that would be nice
[21:37] <wgrant> jcristau: What's special about it?
[21:38] <jcristau> ships some python files that are used when building libxcb
[21:38] <jcristau> and i have no idea how/where to install those
[21:38] <wgrant> Why install them if they're only for building?
[21:38] <tseliot> jcristau: I have provided a patch for an xml to the author, therefore if you need a hand
[21:38] <jcristau> wgrant: they're in xcbproto, they're needed when building libxcb
[21:39] <tseliot> they are automatically generated from the xml files
[21:39] <jcristau> (don't ask me why)
[21:39] <wgrant> Oh.
[21:39] <wgrant> That is just strange.
[21:39] <jcristau> yeah
[21:39] <jcristau> xcbgen/* in proto
[21:39] <wgrant> Where does libxcb look for them?
[21:39] <jcristau> by default they're installed in /usr/share/python2.X/site-packages, which sucks because it depends on the python version
[21:40] <wgrant> OK.
[21:40] <wgrant> So you'll need python-(support|central)
[21:40] <jcristau> that too. but that's not enough
[21:40] <jcristau> that build system is just weird
[21:41] <wgrant> I like to keep away from stuff at that level.
[21:41] <tseliot> jcristau: wgrant is right. Then the files will be installed to /usr/share/pyshared/
[21:41] <jcristau> libxcb looks for them in `pkg-config --variable=pythondir xcb-proto`
[21:41] <wgrant> pkg-config for Python? Kill me now.
[21:42] <tseliot> LOL
[21:42] <jcristau> well. at least pkg-config i can understand somewhat. python not so much
[21:43]  * wgrant wonders how people can not know Python.
[21:44]  * wgrant -> uni
[21:44] <tseliot> jcristau: is the package maintained somewhere (git, bzr, etc.)?
[21:45] <jcristau> the xcb stuff? there's a debian branch upstream, but it's probably outdated
[21:45] <tseliot> yes, xcb-proto
[21:47] <jcristau> let me push what i have somewhere
[21:49] <jcristau> http://git.debian.org/?p=users/jcristau/xcb-proto.git
[21:52] <tseliot> ok, good
[21:52] <tseliot> I'll have a look at the source
[21:52] <jcristau> thanks
[21:53] <tseliot> I will really need that package ;)
[22:34] <sbeattie> bryce: got any ideas on bug 287215 ? Is -evdev even the right component for that to be filed against?
[22:34] <ubottu> Launchpad bug 287215 in xserver-xorg-input-evdev "[intrepid] xmodmap settings not getting honored when keyboard devices are hotplugged" [Undecided,New] https://launchpad.net/bugs/287215
[23:07] <bryce> sbeattie: -evdev probably isn't the right component
[23:08] <bryce> xkeyboard-config might be a better place for it
[23:16] <sbeattie> bryce: okay, done. Any ideas as to where I should be poking to fix it?
[23:20] <jcristau> in the server
[23:38] <bryce> sbeattie: yeah I think tracing in the code to see a) what code is used to set things up with xmodmap, and b) the code that runs when the keyboard is plugged in, and make sure that when b runs, that it appropriately triggers a as well
[23:39] <bryce> sbeattie: short of that, upstream the bug.  :-)
[23:41] <sbeattie> /etc/gdm/Xsession is doing the initial setup of xmodmap. I don't understand hal/udev enough to know what gets invoked in that path.