| bryceh | I did a diff between the upstream 1.11 git tree's include/ dir and ours (before applying debian/patches): http://paste.ubuntu.com/913875/ | 00:00 |
|---|---|---|
| bryceh | didn't spot any commonalities with your valgrind output. mostly it's cnd's touch bits | 00:01 |
| cnd | RAOF, valgrind ioctl warnings are either: correct, or they need wrappers to tell valgrind how they really work | 00:02 |
| cnd | RAOF, I just added wrappers for the uinput ioctls to the precise valgrind | 00:02 |
| cnd | you might be interested in doing the same for drm? | 00:03 |
| RAOF | cnd: Apparently upstream already has; in the libdrm sources - we just need to build-depend on valgrind to get those intrinsics added. | 00:03 |
| cnd | RAOF, that seems odd | 00:03 |
| cnd | the fixes should be in the valgrind sources | 00:04 |
| cnd | I suspect libdrm is either really fixing the issues, or just papering over them | 00:04 |
| RAOF | Ah, no; what it's doing is using some intrinsics to annotate stuff for valgrind - VALGRIND_MAKE_MEM_DEFINED(bo_gem->gtt_virtual, bo->size) and such. | 00:06 |
| RAOF | I think they've *also* fixed an issue or two. | 00:06 |
| cnd | RAOF, ahh, that looks like it makes some sense for drm | 00:07 |
| cnd | drm is funny in how it uses memory :) | 00:08 |
| cnd | RAOF, btw, the ioctl warnings at device init time are red herrings again, I'm fairly certain | 00:09 |
| RAOF | Hm. | 00:09 |
| cnd | the evdev ioctls probably need wrappers too | 00:09 |
| cnd | just like the uinput ones | 00:10 |
| cnd | valgrind assumes that all ioctls take an argument, and the argument is a pointer to valid userspace memory | 00:10 |
| RAOF | There don't seem to be any suspicious writes, which is annoying. | 00:10 |
| cnd | you have to manually tell it if a specific ioctl either: doesn't pass an argument, or passes an argument by value | 00:11 |
| RAOF | But, given I can reproduce this easily, I guess it's time to go poking around in the core. | 00:12 |
| RAOF | To the bat-gdb! | 00:12 |
| cnd | RAOF, what trackpad are you thrashing on? | 00:12 |
| RAOF | A synaptics one. | 00:12 |
| cnd | RAOF, thrashing with one finger? | 00:12 |
| RAOF | Two finger scrolling was the last thing I reproduced it with. | 00:12 |
| cnd | RAOF, does xinput list a touch class for your touchpad? | 00:13 |
| cnd | hooray! a one-liner in the server fixes compiz touchscreen interactions | 00:14 |
| RAOF | cnd: Hm, how do I get xinput to do that? | 00:15 |
| cnd | RAOF, xinput list <device name|id> | 00:15 |
| RAOF | Hm. | 00:15 |
| RAOF | EBADATOM | 00:15 |
| RAOF | For some reason that fails. | 00:15 |
| cnd | I've started seeing that too... | 00:16 |
| cnd | it's next on my list of bugs :) | 00:16 |
| cnd | I was hoping it was just me | 00:16 |
| RAOF | It reports 8 classes though, from which I think you can work out if there'll be a pair of touch classes or not. | 00:17 |
| cnd | RAOF, install utouch-frame-tools | 00:17 |
| cnd | then run utouch-frame-test-x11 <window> | 00:17 |
| cnd | where window is some window other than the root window | 00:17 |
| cnd | it will spit out all devices that have touch classes | 00:17 |
| RAOF | Two touches | 00:19 |
| RAOF | http://paste2.org/p/1965826 | 00:19 |
| cnd | ok | 00:21 |
| cnd | cool | 00:21 |
| cnd | so what you are seeing could be multitouch related | 00:21 |
| cnd | once I fix this bug, I'll thrash on my magic trackpad to see if I can cause any misbehavior | 00:21 |
| cnd | RAOF, is this on a netbook or something else that is less performant? | 00:22 |
| RAOF | Nope, it's on my shiny sandybridge i5 | 00:22 |
| RAOF | However, it's on my shiny sandybridge i5 while running under valgrind, so you may assume it is significantly non-performant :) | 00:22 |
| RAOF | And, as you might note in the valgrind backtrace, the initial SIGSEGV comes from the ErrorF in mieq saying “[mi] EQ overflowing” | 00:27 |
| cnd | RAOF, oh, you're running under valgrind | 00:31 |
| cnd | I'm guessing that you are hitting the queue overflow because it's so slow | 00:31 |
| cnd | is it crashing? | 00:31 |
| RAOF | Yes. | 00:32 |
| RAOF | Yeah, that's exactly what's happening. | 00:32 |
| RAOF | It's queue overflowing. | 00:32 |
| cnd | RAOF, oh, I bet you're hitting the same bug I was seeing yesterday :) | 00:32 |
| RAOF | But! It's SEGVing when trying to print the queue overflow. | 00:32 |
| cnd | if you hit ErrorF within signal context under valgrind | 00:32 |
| cnd | then it will segfault | 00:32 |
| cnd | I think sprintf is technically signal unsafe | 00:32 |
| RAOF | But only under valgrind? | 00:32 |
| cnd | it seems to work when not under valgrind | 00:33 |
| cnd | though that may mean that valgrind always crashes, while in real world it only crashes 1/1000 times | 00:33 |
| RAOF | Right. | 00:33 |
| RAOF | It is indeed not listed as signal safe | 00:33 |
| RAOF | This lacks awesome. | 00:34 |
| cnd | yeah... | 00:34 |
| cnd | I had to stop to look at other things | 00:34 |
| cnd | it should probably be brought up on xorg-devel at the very least though | 00:34 |
| RAOF | Yes. | 00:34 |
| cnd | RAOF, the sprintf is only used to print the timestamp in the X log | 00:35 |
| cnd | so we may be able to get away without it, with some manual number printing | 00:35 |
| cnd | when I commented the sprintf out, I didn't get the crash anymore | 00:35 |
| RAOF | Aha. | 00:36 |
| RAOF | Hm. | 00:38 |
| RAOF | Practically nothing done in ErrorF is signal-safe. | 00:38 |
| RAOF | fwrite: no, memcpy: no, fflush: no. | 00:39 |
| RAOF | Oooh, and if you're unlucky it'll try to realloc | 00:39 |
| RAOF | vsnprintf: no. | 00:42 |
| cnd | fun | 00:42 |
| cnd | RAOF, maybe there should be a separate code path for ErrorF if in signal context? | 00:43 |
| RAOF | Quite possibly. | 00:43 |
| cnd | don't attempt to do anything other than just write directly to the log file | 00:43 |
| cnd | actually, maybe a separate function altogether | 00:43 |
| RAOF | Yes. | 00:43 |
| cnd | and then in ErrorF, merely print "you're dumb" if in signal context | 00:43 |
| cnd | :) | 00:43 |
| cnd | because ErrorF attempts to print a vararg printf style message | 00:44 |
| cnd | which I think may be impossible without reimplementing vsprintf in signal safe code :) | 00:44 |
| RAOF | Probably, yes. | 00:46 |
| cnd | RAOF, bryceh, Sarvatt: I have a one-liner fix for compiz touchscreen interactions for xorg-server | 00:46 |
| cnd | any issues if I upload now? | 00:46 |
| RAOF | None from me. | 00:46 |
| cnd | fixes bug 972985 | 00:47 |
| ubottu | Launchpad bug 972985 in xorg-server (Ubuntu) "XQueryPointer does not return button 1 set when touch on touchscreen is active" [High,In progress] https://launchpad.net/bugs/972985 | 00:47 |
| RAOF | Although what would be much more awesome is to just have a gorram input *thread* and stop futzing around in the SIGIO context. | 00:47 |
| cnd | heh | 00:47 |
| RAOF | We call *so much* code in that context. | 00:47 |
| RAOF | It's scary. | 00:47 |
| cnd | yeah | 00:47 |
| cnd | it seemed like we were so close too... | 00:48 |
| bryceh | cnd, pastebin the patch? | 00:48 |
| cnd | bryceh, 505_query_pointer_touchscreen.patch | 00:48 |
| cnd | oops | 00:48 |
| cnd | http://paste.ubuntu.com/913912/ | 00:48 |
| cnd | I guess it's technically a two-liner :) | 00:49 |
| bryceh | cnd, ok; looking at event_get_corestate this effectively just ORs in mouse->touch->state if defined | 00:53 |
| cnd | bryceh, yep | 00:53 |
| bryceh | heh, you know what, this might fix an issue that I *just* saw about 3 minutes ago | 00:54 |
| bryceh | on my fujitsu touch screen, it responds to touch drag events, but if I just tap with my finger, nothing happens | 00:55 |
| cnd | bryceh, really? | 00:55 |
| bryceh | cnd, does that sound like this? | 00:55 |
| cnd | bryceh, what are you trying to tap? | 00:55 |
| cnd | are you trying to raise a window? | 00:55 |
| bryceh | yeah, or click buttons on the launcher | 00:56 |
| cnd | bryceh, btw, I still have a bug that is locking up the desktop after some touch interactions | 00:56 |
| cnd | I was hoping this would fix it for good, but apparently not | 00:56 |
| bryceh | drags work | 00:56 |
| bryceh | well sort of work. the initial touch doesn't move the cursor, so you end up dragging offset | 00:57 |
| cnd | hmm | 00:57 |
| cnd | bryceh, oh, we just pushed up a fix in utouch-grail | 00:58 |
| cnd | touchscreens are quite broken without version 3.0.5 | 00:58 |
| bryceh | ok. I just updated a couple hours ago | 00:58 |
| cnd | without 3.0.5, grail was holding on to touches until they physically ended | 00:58 |
| bryceh | ok, I've got 3.0.4 installed, I'll try that | 00:59 |
| cnd | that sounds like the issue you are seeing | 00:59 |
| bryceh | fwiw, stylus and eraser work fine in gimp | 00:59 |
| bryceh | ok | 00:59 |
| cnd | good :) | 00:59 |
| cnd | so I see that my pointer lockup is a core passive button grab | 01:00 |
| cnd | I think there are issues in the compiz stack... | 01:00 |
| RAOF | Really? Heaven forfend! | 01:00 |
| RAOF | :) | 01:00 |
| cnd | having peeked at their code today, I'm very afraid | 01:00 |
| Darxus | Same problems with my Radeon with the upstream kernel. | 01:21 |
| RAOF | Darxus: Sarvatt was saying something about lack of radeon-kms in the -edgers packages earlier, but it's dropped off my backscroll. | 01:25 |
| Sarvatt | that was in xorg-edgers | 01:27 |
| Sarvatt | (which its not recommended to even use) | 01:27 |
| Sarvatt | until mesa 8.1 builds in there, its still going through automake changes breaking it every few days and i cant keep up so its on 8.0 branch | 01:28 |
| Sarvatt | which is the same as in precise | 01:28 |
| Sarvatt | wayland egl builds have been broken since the beginning of march for out of tree builds aka what the debian packages do | 01:29 |
| Sarvatt | every automake commit breaks something new because they always include $(top_srcdir) instead of $(top_builddir) | 01:33 |
| Sarvatt | like http://cgit.freedesktop.org/mesa/mesa/commit/?id=ca760181b4420696c7e86aa2951d7203522ad1e8 doing -I$(top_srcdir)/src/mapi ,but that ones fixed already | 01:36 |
| Sarvatt | Darxus: i'm going to push libdrm 2.4.33 and newer x-x-v-ati to x-updates tomorrow for precise, might as well be using that and not have screwed up input like you will in xorg-edgers if you're using that :) | 01:41 |
| Darxus | Sarvatt: I'm not using xorg-edgers. | 01:42 |
| Sarvatt | then again i dont know what problems you really have with radeon, might be assuming too much that you're using edgers because of RAOF :) | 01:42 |
| Darxus | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/971204 | 01:42 |
| ubottu | Launchpad bug 971204 in linux (Ubuntu) "graphics fails with setgfxpayload=keep, AMD Radeon" [Medium,Incomplete] | 01:42 |
| RAOF | Darxus: Sorry, I was confusing you with someone else. | 01:44 |
| Darxus | No problem. | 01:44 |
| Sarvatt | hmm how does grub-gfxpayload-lists have nothing but vmware added in it in precise, i know tjaalton added a bunch of systems to it | 01:46 |
| Sarvatt | all the systems added in the natty lists that were SRUed aren't there, hmm | 01:49 |
| Sarvatt | tjaalton: any idea whats going on there? surely those should be forward ported to later releases | 01:49 |
| * Sarvatt hopes nothing failed certification in 11.10 because it was dropped | 01:50 | |
| bryceh | cnd, btw even after updating to 3.0.5, the fujitsu touchscreen still misbehavin | 03:07 |
| cnd | bryceh, describe what it's doing | 03:07 |
| cnd | I still see some issues here | 03:07 |
| bryceh | the pointer is at position x,y | 03:08 |
| bryceh | you touch at position x+100,y+100 | 03:08 |
| bryceh | the pointer remains at x,y | 03:08 |
| bryceh | you drag your finger from x+100,y+100 to x+150,y+150 | 03:09 |
| bryceh | the pointer moves from x,y to x+50,y+50 | 03:09 |
| cnd | whoa | 03:09 |
| cnd | that's weird | 03:09 |
| cnd | I've not seen that | 03:09 |
| bryceh | actually it's a bit worse | 03:10 |
| cnd | bryceh, it sounds like X thinks your touchscreen is a touchpad | 03:10 |
| cnd | bryceh, can you pastebin your x log? | 03:10 |
| bryceh | there is some scaling going on, so moving by +50/+50 moves pointer say +100/+80 | 03:10 |
| bryceh | pastebin.ubuntu.com/914024 | 03:11 |
| cnd | bryceh, it's using the wacom driver | 03:12 |
| cnd | I think it thinks your touchscreen is a tablet | 03:12 |
| cnd | so its behaving like it's a trackpad for pointing | 03:12 |
| bryceh | ah, hum | 03:12 |
| cnd | bryceh, I don't know if it's multitouch, but the only way to get the full touch experience would be to use the evdev driver | 03:13 |
| bryceh | it is multitouch, but it is a serial interface | 03:13 |
| cnd | bryceh, I think that means you have to use set_serial first | 03:14 |
| cnd | bdmurray was trying to get it to work | 03:14 |
| cnd | I don't know if he made it work out of the box in ubuntu though | 03:14 |
| bryceh | set_serial via xinput? | 03:15 |
| cnd | no, it's a separate utility | 03:15 |
| cnd | bryceh, http://www.murraytwins.com/blog/?p=103 | 03:15 |
| bryceh | alright, well I'll mess with it more some day. | 03:15 |
| cnd | looks like I meant inputattach | 03:16 |
| Sarvatt | sucks most all touchscreens are wacom these days :( | 03:24 |
| cnd | or ntrig.. | 03:28 |
| Sarvatt | cnd: xt3 and m6600 were the only ntrigs that ever shipped with ubuntu, everyone else switched to wacom in the past few years :( | 04:21 |
| Sarvatt | (since i started tracking it in 2010) | 04:22 |
| Sarvatt | x220 tablet, all lenovo W series touchscreens switched to wacom | 04:24 |
| Sarvatt | reviews of xt3 were saying it was a negative it still used "ntrig crap" | 04:24 |
| cnd | Sarvatt, the dell xps 15 and 17 are still available with it | 04:30 |
| cnd | but yeah, I don't blame them | 04:30 |
| cnd | I don't know why we can't get an atmel maxtouch touchscreen in an x86 laptop | 04:31 |
| tjaalton | Sarvatt: they worked with 3.0, so the quirks were only needed for 11.04 | 04:47 |
| mornau | hi, i'm trying to get a copy of the linux 3.2.0-21.34 kernel build by/for xorg-edgers: https://launchpad.net/~xorg-edgers/+archive/ppa/+build/3379667 | 11:41 |
| mornau | but i can't seem to find it in the repository. | 11:42 |
| mornau | is it still awaiting an upload? | 11:42 |
| ricotz | mornau, it should be available, try run "apt-get update" again | 12:22 |
| mornau | ricotz: i did this right before posting but there was no updated package available, yet. it worked this time, though. | 12:25 |
| mornau | btw i'm gettnig this warning when installing the package: W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for module r8169 | 12:25 |
| mornau | i also got it for the current image (the last 3.2 kernel from the edgers repository), though, and it least for me networking isdoing fine. | 12:26 |
| ricotz | right, linux-firmware isnt updated to include the new firmware binaries | 12:27 |
| ricotz | Sarvatt, do you think it is safe and worth to put an update linux-firmware package in edgers too? | 12:28 |
| === Darxus_ is now known as Darxus | ||
| mornau | ricotz, Sarvatt: i'm on your linux-image 3.2.0-20.32 now, but DHCP issues remain: "dhclient: Error creating socket to list interfaces; Permission denied." this then results in: "NetworkManager[1520]: <info> (eth0): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]". also the libvirt-bin process keep getting terminated by apparmor and keeps respawning. | 14:10 |
| mornau | type=1400 audit(1333548406.883:1402): apparmor="DENIED" operation="create" parent=1 profile="/usr/sbin/libvirtd" pid=31996 comm="libvirtd" family="inet" sock_type="dgram" protocol=0 | 14:11 |
| mornau | both doesn't happen with the oneiric linux image. i'm happy o file proper bug reports if that's of help. if so, please explain what to file those against. | 14:12 |
| ricotz | mornau, please try 3.2.0-21.34 first, note this is a plain rebuild of the current official precise kernel | 14:15 |
| ricotz | mornau, so you have a r8169 ethernet device and not having the updated firmware files seems to cause problems? | 14:15 |
| mornau | ricotz: sorry i pasted the wrong version there, i'm actually on 3.2.0-21.34 and the above report refers to this version (but also to 3.2.0-21.34) | 14:16 |
| mornau | ... but also to 3.2.0-20.32 | 14:17 |
| ricotz | mornau, could you try https://launchpad.net/ubuntu/+source/linux-firmware/1.78/+build/3380028/+files/linux-firmware_1.78_all.deb | 14:17 |
| mornau | i do have a r8169 ethernet device. i would be surprised if this caused dhcp to fail but static ip assignment to work | 14:19 |
| mornau | i'm currently using static ip assignment | 14:19 |
| mornau | (i also have multiple NICs) | 14:19 |
| ricotz | mornau, the newer kernel seems to rely on the newer firmware and this might fix this problem | 14:20 |
| mornau | okay, i'll try with the firmware, thanks | 14:20 |
| Sarvatt | ricotz: no problems from me putting firmware in there | 14:25 |
| Sarvatt | thats really strange he's hitting that though, maybe libvirt's apparmor profile in oneiric doesn't work wth precise's kernel apparmor? | 14:26 |
| * Sarvatt has no clue about apparmor really | 14:26 | |
| ricotz | Sarvatt, ok, -21.34 contains a lot appamor changes/fixes | 14:27 |
| ricotz | Sarvatt, i will copy the firmware package to the ppa | 14:31 |
| ricotz | Sarvatt, but this is probably a problem for lts-backports of the kernel too | 14:32 |
| ricotz | apw, hi ^ | 14:32 |
| mornau | ricotz: i installed the firmware package you pointed me to, ran "sudo update-initramfs -u -k all", rebooted, to no effect. | 14:41 |
| mornau | # dpkg -l linux-firmware\* | grep ^ii ii linux-firmware 1.78 Firmware for Linux kernel drivers | 14:42 |
| mornau | hmm silly qwebirc, it eats line wraps. but i guess you know what this output should loook like. | 14:43 |
| mornau | i also reinstalled the kernel image and there were no more warnings about possibly missing firmware. | 14:47 |
| apw | ricotz, you saying there is a new dependancy between the kernel and firmware in precise? | 14:49 |
| apw | ricotz, there won't be a precise lts backport to lucid iirc | 14:50 |
| ricotz | mornau, i see, i am not that familiar with libvirt | 14:50 |
| ricotz | apw, ok, but i saw a similar issue with the 3.0 backport | 14:51 |
| ricotz | apw, .. complaining about missing nouveau firmware files | 14:51 |
| apw | ricotz, stupid backports, make life so difficult | 14:52 |
| ricotz | apw, so this also effects the oneiric ltsp backport | 14:52 |
| ricotz | *lts | 14:52 |
| apw | ricotz, could you file a bug against the kernel with the details | 14:52 |
| ricotz | apw, yeah, i know, another problem is also not having an updated linux-libc | 14:52 |
| mornau | ricotz: it's an issue with its apparmor profile, i guess. i don't need libvirt really so i just purged it. dhclient not working is a bit of a show stopper though. (so unless you want me to look into this more) i guess i'll just downgrade to the oneiric images until precise is released. thanks so far. | 14:53 |
| ricotz | mornau, yeah, might be the best to use the oneiric kernel then, sorry for the trouble | 14:55 |
| * Sarvatt would just purge apparmor instead :P | 14:58 | |
| Sarvatt | looking at the apparmor bugs it looks like mismatched apparmor kernel and userspace breaks dhclient all the time though :( | 14:59 |
| Sarvatt | same bugs filed in maverick and natty | 14:59 |
| ricotz | so much for abi stability ;) | 15:00 |
| mornau | :)) | 15:00 |
| * ricotz is surprisingly happy with 3.4rc1 so far | 15:02 | |
| Sarvatt | and karmic and jaunty, thats a deep rabbit hole of a problem :) | 15:02 |
| mlankhorst | still on 3.2 here :) | 15:07 |
| apw | ricotz, linux-libc-dev being 'downrev' is deliberate as in theory at least the interfaces are backwards compatible | 15:10 |
| apw | therefore you want to build things for the oldest interface on the machine | 15:10 |
| ricotz | apw, hmm, i see, putting the kernel package in xedgers is mostly for this reason to have an updated linux-libc-dev | 15:14 |
| apw | ricotz, well in there you may be using newer things which need the newer interfaces for instance | 15:14 |
| ricotz | since it is expecting people using xedgers would use a newer kernel too | 15:14 |
| apw | ricotz, its all a bit of a mess. actually we should not really offer a backport kernel, but a backport ppa for each release to contain this crap | 15:15 |
| ricotz | yeah, while having libdrm git and kernel git would fit more | 15:15 |
| ricotz | apw, having a ppa might lead to more inconsistencies while x-backports are starting next cycle | 15:17 |
| apw | ricotz, well i think i mean there needs to be one PPA for each source series destination series, with kernel, mesa, X etc in for that combination | 15:17 |
| ricotz | ah, i see | 15:18 |
| apw | there is no other safe way to do it imo, anyhow ... fun | 15:18 |
| ricotz | i think this should also get stricter tied together | 15:19 |
| ricotz | so wanting a newer x should suggest you a newer kernel | 15:19 |
| ricotz | (or even force you) | 15:20 |
| Sarvatt | ricotz: like having a new pocket for each backport series, and having the kernel be called linux and all of the x packages having the same names too? :P | 15:20 |
| ricotz | Sarvatt, yeah, this would be way easier to be maintained | 15:21 |
| Sarvatt | we're gonna get so much wrong namespacing all of x/mesa/libdrm the way lts backport kernels do | 15:21 |
| apw | Sarvatt, you describe Nirvana | 15:21 |
| === lool- is now known as lool | ||
| cnd | bryceh, RAOF: just got a good valgrind trace on X :) | 19:05 |
| cnd | oh wait, it might be in the area where I was patching stuff in | 19:05 |
| cnd | for debugging :( | 19:05 |
| cnd | hmm, I think I found issues though | 19:11 |
| cnd | I don't know if people would see them outside of touchscreen cases though | 19:12 |
| bryceh | cnd, awesome | 19:29 |
| cnd | yeah, the way we look for pointer listeners for direct touch devices is all wrong right now | 19:31 |
| cnd | the code is looking at the wrong event masks | 19:31 |
| cnd | it's looking at the core event mask, but interpreting it as a pointer to an XI2 event mask | 19:31 |
| cnd | so it's all wrong | 19:31 |
| bryceh | cnd, is that something due to the mixed server stack, or a legit upstream bug? | 19:50 |
| cnd | legit upstream | 19:50 |
| cnd | it just hasn't been tested properly, basically | 19:51 |
| bryceh | ok | 19:52 |
| tjaalton | bryceh: the 'touchscreen is reset to relative mode' is likely a bug in g-s-d or so, since it's happening after login | 20:50 |
| tjaalton | bug 949097 was filed earlier | 20:50 |
| ubottu | Launchpad bug 949097 in xf86-input-wacom (Ubuntu) "Serial Wacom Tablet touch not in absolute mode when logged in" [Undecided,Incomplete] https://launchpad.net/bugs/949097 | 20:50 |
| bryceh | friggin gnome | 20:51 |
| tjaalton | :) | 20:52 |
| bryceh | so yeah, then 973133 would be a dupe of that. was just looking at that a bit ago | 20:52 |
| bryceh | is there a bug against g-s-d yet? | 20:52 |
| tjaalton | no, probably would be right to add it to the earlier bug, until it's clear the bug is there | 20:53 |
| tjaalton | since the login screen should be running g-s-d as well.. | 20:53 |
| tjaalton | hmm | 20:55 |
| tjaalton | would be easy to test | 20:55 |
| tjaalton | by disabling the wacom plugin | 20:55 |
| Sarvatt | its not running g-s-d plugins though | 20:55 |
| tjaalton | right | 20:55 |
| tjaalton | realized that | 20:55 |
| tjaalton | actually, the bug might be that the touchscreen isn't actually reported as one by the kernel | 20:56 |
| tjaalton | but a tablet | 20:56 |
| tjaalton | where relative mode makes sense | 20:56 |
| tjaalton | hmm no | 20:56 |
| tjaalton | it should be in relative mode in the login screen as well then | 20:57 |
| tjaalton | bryceh: so, flip the wacom plugin off, org.gnome.settings-daemon.plugins.gsdwacom:active, and login again | 20:59 |
| bryceh | alrighty, is there a utility for turning it off, or a config file? | 21:01 |
| tjaalton | dconf-editor, or gsettings | 21:02 |
| tjaalton | gsettings set org.gnome.settings-daemon.plugins.gsdwacom active false | 21:04 |
| tjaalton | then 'get ... active' to check that it worked | 21:04 |
| bryceh | yep, that did the trick | 21:07 |
| bryceh | works properly on both login screen and logged in | 21:07 |
| tjaalton | whee | 21:07 |
| bryceh | stylus and eraser also working | 21:07 |
| tjaalton | yeah those should've worked before too | 21:08 |
| bryceh | they did, was just checking that they still did ;-) | 21:08 |
| tjaalton | hehe, right | 21:08 |
| cnd | bryceh, have you seen any bugs where people are attempting to perform a two touch tap on a trackpad and it is generating a middle button click instead of right? | 21:14 |
| cnd | olli ries, my manager, is seeing it | 21:14 |
| cnd | first, the defaults in X are wrong due to a distro patch from 2009 :) | 21:14 |
| cnd | but then gsd should be overwriting the config | 21:14 |
| cnd | which is why no one sees the issue | 21:15 |
| bryceh | cnd, not that I remember offhand, but I can take a quick scan | 21:50 |
| cnd | bryceh, this is the bug olli filed: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/973784 | 21:50 |
| ubottu | Launchpad bug 973784 in gnome-settings-daemon (Ubuntu) "configuration not set properly" [Undecided,New] | 21:50 |
| cnd | it seems like something someone might toss in the X package bugs mistakenly | 21:50 |
| bryceh | bug 972125 maybe | 21:53 |
| ubottu | Launchpad bug 972125 in xserver-xorg-input-synaptics (Ubuntu) "Right and middle mouse button do not work on clickpad" [Undecided,New] https://launchpad.net/bugs/972125 | 21:53 |
| bryceh | there's lots of reports of touchpads that just stop working entirely after thus and such | 21:53 |
| bryceh | bug 972727 | 21:54 |
| ubottu | Launchpad bug 972727 in xinput (Ubuntu) "Synaptics Clickpad functionalities incomplete: Right button area, two-tap disabling" [Undecided,New] https://launchpad.net/bugs/972727 | 21:54 |
| === yofel_ is now known as yofel | ||
| cnd | ok, I got another patch for the xserver today :) | 22:56 |
| * cnd knocks down more bugs | 22:56 | |
| bryceh | :-) | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!