Sarvatt | bryceh: amazing how many people are trying to literally run apport-collect BUGNUMBER in response to your automated replies :D | 02:02 |
---|---|---|
RAOF | Sarvatt: Good $TIME_OF_DAY | 02:26 |
RAOF | Is there anyone around to sponsor an xserver-xorg-video-intel upload? We need to drop the DRI-disablement patch before release. | 02:41 |
rafiyr | I need a touch of help debugging driver assignment for an input device. | 05:41 |
RAOF | I'm not particularly experienced in that area, but need experience in that sort of debugging. want to learn together? :) | 05:49 |
rafiyr | Sure | 05:50 |
rafiyr | Let the fun begin | 05:50 |
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:51 |
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:52 |
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:53 |
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:54 |
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:55 |
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:56 |
rafiyr | interesting | 05:58 |
rafiyr | Have to admit, that I'm still just used to configuring everything myself | 05:58 |
RAOF | I know why. It's relatively easy to do, once you've learnt how. | 05:59 |
rafiyr | And this automated stuff just makes life so much harder | 06:01 |
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:02 |
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:03 |
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:04 |
RAOF | Or possibly just MatchIsTouchscreen "on" ? | 06:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
rafiyr | yeah, been working with him for a while now | 06:11 |
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:12 |
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:14 |
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:15 |
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:18 |
rafiyr | Seems to me that when you only have 2 buttons, right trumps middle | 06:19 |
RAOF | Ack. | 06:22 |
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:28 |
rafiyr | ok | 06:29 |
ricotz | RAOF, hello | 06:30 |
RAOF | ricotz: Howdie. | 06:31 |
ricotz | RAOF, are you using edgers ppa with nouveau? | 06:31 |
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:32 |
ricotz | RAOF, ok | 06:33 |
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:34 |
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:36 |
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:42 |
ricotz | i know, having 8gb ;-), it will take some time to fill them | 06:43 |
rafiyr | RAOF: thanks for your help. I'd better get some sleep. btw, a user had already opened a bug. | 06:53 |
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. | 07:57 |
KiBi | /C/C | 11:58 |
KiBi | hmpf. :) | 11:59 |
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:08 |
bjsnider | RAOF, what hardware does the netbook have? | 13:26 |
tseliot | mvo: ah, so that was the problem | 13:46 |
tseliot | mvo: thanks for dealing with that report | 14:34 |
mvo | np | 14:35 |
=== vish is now known as Vish | ||
=== Vish is now known as vish | ||
=== vish is now known as Vish | ||
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] | 16:41 |
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:04 |
Ng | eep, just updated the X40 since all the DRI disablement got dropped, and it won't start X | 21:42 |
Ng | with -intel 2:2.9.1-3ubuntu4 or 5 (the only two debs on there). I just get a black screen | 21:43 |
Ng | aha, it's the kernel | 21:46 |
Ng | -19 works, -21 doesn't | 21:46 |
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:51 |
Ng | hrm, and now an oops from -20 in intel_release_load_detect_pipe | 22:55 |
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:08 |
bryceh | apw, ^^ we're getting a lot of anti-votes for blacklisting kms on 8xx | 23:43 |
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:44 |
ilmari | bryceh: any tips on debugging #568138? | 23:46 |
ilmari | deadlock in i915_gem_*_ioctl | 23:46 |
bryceh | ilmari, nope | 23:46 |
bryceh | nothing beyond the usual anyway. see the ubuntu-x wiki. | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!