[02:02] <Sarvatt> bryceh: amazing how many people are trying to literally run apport-collect BUGNUMBER in response to your automated replies :D
[02:26] <RAOF> Sarvatt: Good $TIME_OF_DAY
[02:41] <RAOF> Is there anyone around to sponsor an xserver-xorg-video-intel upload?  We need to drop the DRI-disablement patch before release.
[05:41] <rafiyr> I need a touch of help debugging driver assignment for an input device.
[05:49] <RAOF> I'm not particularly experienced in that area, but need experience in that sort of debugging.  want to learn together? :)
[05:50] <rafiyr> Sure
[05:50] <rafiyr> Let the fun begin
[05:51] <RAOF> So, what's the problem?
[05:51] <rafiyr> I'm just trying to verify the n-trig stuff gets setup correctly.  Its a pen+multitouch sensor in the screen
[05:51] <rafiyr> Atm, the wacom driver is best for the pen and evdev for touch.
[05:52] <rafiyr> And lucid beta 1 was assigning them correctly (I think).  But the current images are assigning both to evdev.
[05:52] <rafiyr> There seem to be pattern matches for all sorts of stuff in /lib/udev/rules.d and /usr/lib/X11/xorg.conf.d
[05:53] <RAOF> I think that we switched to the xorg.conf.d work between beta 1 and now.  This would probably be the cause of the switch.
[05:53] <rafiyr> And I tweaked both (when booting off a live image on a usb stick)
[05:53] <RAOF> Right.  My understanding of the way these interact is that udev can tag devices with particular information, and the rules in xorg.conf.d use that information to match appropriately.
[05:53] <rafiyr> So if I change the files in that dir, should an X (gdm) restart reassign the drivers?
[05:54] <rafiyr> Or am I going to have to poke at the image before booting on it?
[05:54] <RAOF> That is my understanding.
[05:54] <rafiyr> hm
[05:54] <RAOF> You shouldn't have to reboot.
[05:55] <rafiyr> 2 minutes until my usb stick is ready for another test (decided to clean it before trying again)
[05:55] <RAOF> Unless you're fiddling with udev rules; I believe that would require that you re-run the udev scanning stuff, which might not be possible on a running system.
[05:55] <rafiyr> I tried fiddling with udev, hal/fdi, and the xorg.conf.d and restarted all the udev services and gdm
[05:56] <rafiyr> but let me try just fiddling with xorg.conf.d when it comes back up
[05:56] <RAOF> https://fedoraproject.org/wiki/Input_device_configuration is some documentation, if you haven't found it yet.
[05:56] <RAOF> Stupid killswitch.  Keeps getting accidentally triggered.
[05:58] <rafiyr> interesting
[05:58] <rafiyr> Have to admit, that I'm still just used to configuring everything myself
[05:59] <RAOF> I know why.  It's relatively easy to do, once you've learnt how.
[06:01] <rafiyr> And this automated stuff just makes life so much harder
[06:02] <RAOF> Until it works, at which point you no longer notice it :)
[06:02] <rafiyr> Like screen resolutions and dpms.  One of my video drivers started deciding it knows best, and since I didn't use a compliant identifier for my monitor, it ignored my modelines.
[06:03] <rafiyr> Yeah, hoping so.  This n-trig stuff certainly is a pain without auto-config.  The best way to use it seems to be to target 2-3 event nodes, which of course may move around on every boot
[06:04] <RAOF> Without knowing the details of the hardware, it would seem to me that you should be able to match on Vendor and/or Device to do that configuration?
[06:05] <RAOF> Or possibly just MatchIsTouchscreen "on" ?
[06:06] <rafiyr> Have to match the product id (thanks for that link the explanation of the pattern keys helped) since I want to use different drivers for the pen and touch
[06:06] <rafiyr> (added the sensor types to the name in the kernel a couple months ago)
[06:06] <RAOF> Aha!
[06:07] <rafiyr> So, if you have a pen, how would you assign the buttons
[06:07] <rafiyr> the tip is of course left click or btn0 (or 1 depending on who you ask)
[06:07] <rafiyr> there is a barrel switch, which seems to default to btn 2 (middle)
[06:08] <rafiyr> and a button a little further up the side which switches to eraser
[06:08] <rafiyr> but in eraser mode that too emits a left click for normal desktop use
[06:08] <RAOF> What does the tip button emit when in eraser mode?
[06:09] <rafiyr> left
[06:09] <rafiyr> seems to me to be a bit wasteful
[06:09] <RAOF> It's always left, as is the erasor buttor?  That's… odd.
[06:10] <rafiyr> I personally map them to tip left, tip+barrel -> right, and tip+eraser -> middle
[06:10] <RAOF> Incidentally, I know that bryceh is doing some multitouch work with an n-trig device - you might want to check in with him when it's not 10pm on a Sunday :)
[06:11] <rafiyr> yeah, been working with him for a while now
[06:12] <RAOF> I've never really played with a pen, so I'm not sure what the ergonomic constraints are on button placement :)
[06:12] <rafiyr> Yeah, I figure I should figure out who is familiar with the conventions so I can maintain some consistency
[06:14] <RAOF> So the n-trig stuff isn't working out of the box on the RC?  It sounds like we should be able to fix that.
[06:14] <rafiyr> well, that link was what I needed, so thank you for that.  I figure the rest is just tuning and shouldn't be a problem once I figure out what the proper behavior is.
[06:14] <rafiyr> Well, 1 line in 10-wacom.conf
[06:14] <rafiyr> MatchProduct "N-Trig Pen"
[06:15] <rafiyr> instead of "HID 1B96:0001"
[06:15] <rafiyr> but I'm experimenting with the button maps now, to see if I can make those sensible
[06:18] <rafiyr> Gimp only seems to draw on button1.  So I'd better leave that one alone.  But I see no reason not to prefer right over middle for the button on the side of the pen
[06:19] <rafiyr> Seems to me that when you only have 2 buttons, right trumps middle
[06:22] <RAOF> Ack.
[06:28] <rafiyr> I suppose I should open a bug report and email a few people
[06:28] <RAOF> A bug report would be good; xserver-xorg-input-watcom seems like a good target.
[06:29] <rafiyr> ok
[06:30] <ricotz> RAOF, hello
[06:31] <RAOF> ricotz: Howdie.
[06:31] <ricotz> RAOF, are you using edgers ppa with nouveau?
[06:32] <RAOF> I have been in the past.
[06:32]  * RAOF is currently using the nvidia netbook to test out GPU video decoding capabilities.
[06:32] <ricotz> for me with xserver 1.8 , X freezes on logout
[06:33] <ricotz> RAOF, ok
[06:34] <RAOF> I haven't tested xserver 1.8; there's still a bit of fallout from the way upstream fixed the GEM object leak, though.  It's possible you're seeing that.
[06:34] <RAOF> Or just some other random X bug! :)
[06:36] <ricotz> i am seeing no other problem, 3d is working fine, and so on, only when i try to shutdown X it freezes, but i am not sure if nouveau or xserver is the problem here
[06:36] <ricotz> the gem_object leak is no problem for me, enough ram here
[06:42] <RAOF> ricotz: Either you're restarting X frequently, or you'd be noticing the GEM leak; even with 4 GiB you'll notice when 3GiB have been stolen by gem :)
[06:43] <ricotz> i know, having 8gb ;-), it will take some time to fill them
[06:53] <rafiyr> RAOF: thanks for your help.  I'd better get some sleep.  btw, a user had already opened a bug.
[07:57] <RAOF> I wish i915 was slightly less *totally silent* during startup.  It might be nice if it mentioned what displays it thought were connected, for example.
[11:58] <KiBi> /C/C
[11:59] <KiBi> hmpf. :)
[13:08] <mvo> tseliot: I updated bug #568041 (if you haven't see already), it would be interessting to ask him to re-test with network
[13:08] <ubottu> Launchpad bug 568041 in jockey "[Lucid] Upgrade from Karmic broke nVidia installation on cdrom only upgrade (without network)" [Undecided,Won't fix] https://launchpad.net/bugs/568041
[13:08] <mvo> tseliot: but I think it will work just fine then (it does for me)
[13:26] <bjsnider> RAOF, what hardware does the netbook have?
[13:46] <tseliot> mvo: ah, so that was the problem
[14:34] <tseliot> mvo: thanks for dealing with that report
[14:35] <mvo> np
=== vish is now known as Vish
=== Vish is now known as vish
=== vish is now known as Vish
[16:41] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/565981/comments/77 -- that is a very good point, the slowdown that lead to those reverts was indeed the memory leak problem
[16:41] <ubottu> Ubuntu bug 565981 in xorg-server "[KMS] gem objects not deallocated" [Critical,Fix released]
[21:04] <LLStarks> OpenGL vendor string: VMware, Inc.
[21:04] <LLStarks> OpenGL renderer string: Gallium 0.4 on i915 (chipset: 945GM)
[21:04] <LLStarks> OpenGL version string: 1.3 Mesa 7.9-devel
[21:04] <LLStarks> i find that to be very sexy.
[21:42] <Ng> eep, just updated the X40 since all the DRI disablement got dropped, and it won't start X
[21:43] <Ng> with -intel 2:2.9.1-3ubuntu4 or 5 (the only two debs on there). I just get a black screen
[21:46] <Ng> aha, it's the kernel
[21:46] <Ng> -19 works, -21 doesn't
[22:51] <Ng> -20 works too
[22:51] <Ng> bryceh: please can I be more important than the people who wanted 8086:3582 blacklisted from KMS? ;)
[22:55] <Ng> hrm, and now an oops from -20 in intel_release_load_detect_pipe
[23:08] <bryceh> Ng, my eyes don't matter - you need kernel team luv
[23:08] <bryceh> Ng, any changes to that now would require rolling a kernel change
[23:43] <bryceh> apw, ^^  we're getting a lot of anti-votes for blacklisting kms on 8xx
[23:44] <bryceh> Ng, it would be interesting if you booted the kernel with the blacklist (-21 or newer) and see if it works if you force kms on (i915.modeset=1) if it starts working
[23:46] <ilmari> bryceh: any tips on debugging #568138?
[23:46] <ilmari> deadlock in i915_gem_*_ioctl
[23:46] <bryceh> ilmari, nope
[23:47] <bryceh> nothing beyond the usual anyway.  see the ubuntu-x wiki.