**** BEGIN LOGGING AT Sun Feb 20 02:59:57 2011 Feb 20 03:22:00 i just installed maverick from the preinstalled image and i'm getting anything on the dvi out Feb 20 03:22:13 i'm not* Feb 20 07:36:51 noes natty have better touch drivers that maverick Feb 20 07:37:04 does* Feb 20 07:37:13 Ought do, but depends on hardware. Feb 20 07:37:17 ok Feb 20 07:37:44 well Xorg doesnt want to recognise touch events in maverick Feb 20 07:37:49 There may be some noise due to specific issues, but for the most part you should see only the difference between 2.6.35 and 2.6.38 Feb 20 07:38:11 With which hardware? Feb 20 07:38:25 but the mtdev tools and utouch register the touch events Feb 20 07:38:28 Galaxy Tab Feb 20 07:39:12 AT42QT602240 touch panel Feb 20 07:39:19 Ah, if you're seeing events with mtdev and utouch, you have kernel support. I wouldn't expect any differences between maverick and natty in terms of driver support. Feb 20 07:39:41 hm Feb 20 07:40:04 I do not know what driver to use for it though Feb 20 07:40:27 evdev/evtouch dont seem to register events Feb 20 07:40:32 evdev segfaults Feb 20 07:40:32 It's probably worth tracing the events through the stack: while I'm convinced you're getting something useful from the kernel to userspace, there's some chance that you have a strange set of events that doesn't cause changes in X or Y. Feb 20 07:40:52 Excellent! segfaults make debugging easy. Feb 20 07:41:02 utouch gives X/Y events Feb 20 07:41:22 Dig up a stack trace, and determine what is out of bounds, has an unexpected value, etc. That ought show what isn't handling. Feb 20 07:41:30 If utouch gives X/Y events, what isn't working? Feb 20 07:41:57 well evdev segfaults Feb 20 07:42:05 the other drivers just dont register touches Feb 20 07:42:32 how would I go about getting that stacktrace Feb 20 07:43:21 Either enable apport, and fiddle with apport-retrace, or attach gdb pre-segfault, and ask gdb for "bt full" Feb 20 07:43:42 You'll want the appropriate debugging symbols installed for whatever is segfaulting (and sometimes that ends up crossing layers) Feb 20 07:58:01 persia: how would i attach gdb to it Feb 20 07:58:19 cause attaching to x and its pid doesnt give me anything Feb 20 08:09:11 https://wiki.ubuntu.com/X/Debugging is probably a good place to start. I don't know that much about precisely how the layers interact: most of my input work has been at the /dev/input level Feb 20 08:09:54 ah ok Feb 20 08:13:54 persia: http://pastie.org/1584978 Feb 20 08:16:02 Next: go dig in the source. Find out what miDCRestoreUnderCursor does. Find out what is does with those arguments. Feb 20 08:16:23 kernel or the x driver Feb 20 08:16:54 apt-file is your friend: you're looking for midispcur.c Feb 20 08:17:12 ah ok Feb 20 08:17:16 If that doesn't work, I'd try X first, but could be the kernel. Feb 20 08:18:47 Anyway, the problem might not actually be at the place the segfault happens: sometimes the bug is a few levels up. I'll recommend going up and down the stack a couple times, to make sure you understand what is going on. At some point, I suspect you'll suddenly realise the nature of the bug. Most patches tend to be obvious (check a return value, add bounds checking, catch an exception, initialise a variable before using it, etc.) Feb 20 10:10:52 persia: turns out that miDCRestoreUnderCursor is missing Feb 20 10:25:51 Heh. Either make sure it's not implied by the structural definition, OR implement it, and everything ought be fine. Feb 20 10:27:13 hm Feb 20 10:27:20 I am wondering what calls it though Feb 20 10:30:00 miSpriteRemoveCursor() Feb 20 10:30:25 Each frame in the stack represents a call: dig back until you find something that exists. Feb 20 10:30:54 Be aware that X tends to have a pluggable model, so that functions tend to be defined as structures, with some implementaitons providing more than others. Feb 20 10:31:49 There's supposed to be matching declarations, so that nothing not implemented is declared, but it's easy to drop the ball between headers and implementation, especially if one is attempting to implement some other driver and copied the headers. Feb 20 10:32:04 hm Feb 20 10:32:18 thing is this is just using xorg from apt Feb 20 10:33:44 Sure, but that doesn't imply anything particular about the folk who wrote it. Feb 20 10:33:52 heh Feb 20 10:34:26 People make mistakes. Software has bugs. If we can find them, it's best if we can track down the reason, and try to fix. Most folk who maintain software tend to be very glad when someone catches something they dropped. Feb 20 10:35:39 And lots of times, especially for X, it seems that folk implement only enough to meet their test cases, rather than attempting any sort of top-down approach for full function coverage: there's heaps left for other folk to implement if they need it. Feb 20 10:37:12 hm Feb 20 10:37:25 I don't know enough about how x works :/ **** ENDING LOGGING AT Mon Feb 21 02:59:57 2011