| === _bruce_ is now known as _bruce | ||
| === asac_ is now known as asac | ||
| xerebz | i just installed maverick from the preinstalled image and i'm getting anything on the dvi out | 03:21 |
|---|---|---|
| xerebz | i'm not* | 03:21 |
| lilstevie | noes natty have better touch drivers that maverick | 07:36 |
| lilstevie | does* | 07:36 |
| persia | Ought do, but depends on hardware. | 07:36 |
| lilstevie | ok | 07:36 |
| lilstevie | well Xorg doesnt want to recognise touch events in maverick | 07:37 |
| persia | 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 | 07:37 |
| persia | With which hardware? | 07:37 |
| lilstevie | but the mtdev tools and utouch register the touch events | 07:38 |
| lilstevie | Galaxy Tab | 07:38 |
| lilstevie | AT42QT602240 touch panel | 07:38 |
| persia | 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. | 07:38 |
| lilstevie | hm | 07:39 |
| lilstevie | I do not know what driver to use for it though | 07:39 |
| lilstevie | evdev/evtouch dont seem to register events | 07:40 |
| lilstevie | evdev segfaults | 07:40 |
| persia | 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. | 07:40 |
| persia | Excellent! segfaults make debugging easy. | 07:40 |
| lilstevie | utouch gives X/Y events | 07:40 |
| persia | Dig up a stack trace, and determine what is out of bounds, has an unexpected value, etc. That ought show what isn't handling. | 07:40 |
| persia | If utouch gives X/Y events, what isn't working? | 07:41 |
| lilstevie | well evdev segfaults | 07:41 |
| lilstevie | the other drivers just dont register touches | 07:41 |
| lilstevie | how would I go about getting that stacktrace | 07:42 |
| persia | Either enable apport, and fiddle with apport-retrace, or attach gdb pre-segfault, and ask gdb for "bt full" | 07:42 |
| persia | You'll want the appropriate debugging symbols installed for whatever is segfaulting (and sometimes that ends up crossing layers) | 07:43 |
| lilstevie | persia: how would i attach gdb to it | 07:57 |
| lilstevie | cause attaching to x and its pid doesnt give me anything | 07:57 |
| persia | 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 | 08:08 |
| lilstevie | ah ok | 08:09 |
| lilstevie | persia: http://pastie.org/1584978 | 08:13 |
| persia | Next: go dig in the source. Find out what miDCRestoreUnderCursor does. Find out what is does with those arguments. | 08:15 |
| lilstevie | kernel or the x driver | 08:16 |
| persia | apt-file is your friend: you're looking for midispcur.c | 08:16 |
| lilstevie | ah ok | 08:16 |
| persia | If that doesn't work, I'd try X first, but could be the kernel. | 08:16 |
| persia | 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.) | 08:18 |
| lilstevie | persia: turns out that miDCRestoreUnderCursor is missing | 10:10 |
| persia | Heh. Either make sure it's not implied by the structural definition, OR implement it, and everything ought be fine. | 10:25 |
| lilstevie | hm | 10:26 |
| lilstevie | I am wondering what calls it though | 10:26 |
| persia | miSpriteRemoveCursor() | 10:29 |
| persia | Each frame in the stack represents a call: dig back until you find something that exists. | 10:30 |
| persia | 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. | 10:30 |
| persia | 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. | 10:31 |
| lilstevie | hm | 10:31 |
| lilstevie | thing is this is just using xorg from apt | 10:31 |
| persia | Sure, but that doesn't imply anything particular about the folk who wrote it. | 10:33 |
| lilstevie | heh | 10:33 |
| persia | 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. | 10:34 |
| persia | 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. | 10:35 |
| lilstevie | hm | 10:36 |
| lilstevie | I don't know enough about how x works :/ | 10:37 |
| === ogra is now known as Guest96219 | ||
| === Guest96219 is now known as ogra_ | ||
| === jkridner_ is now known as jkridner | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!