| solarion | anyone know what the status is with elantech touchpads? | 05:32 |
|---|---|---|
| wgrant | solarion: I believe it's waiting on kernel support - see bug #123775. | 07:11 |
| ubottu | Launchpad bug 123775 in linux "Elantech touchpad is incorrectly recogonised as a "ImPS/2 Logitech Wheel Mouse"" [Unknown,Confirmed] https://launchpad.net/bugs/123775 | 07:11 |
| tjaalton | wgrant: I've uploaded inputproto and libxi to my ppa, xserver to follow. includes the API changes | 07:33 |
| wgrant | tjaalton: SHall we get people for whom xinput is erroring for to test them? | 07:39 |
| tjaalton | wgrant: no synaptics yet | 07:39 |
| tjaalton | or xinput | 07:39 |
| wgrant | Well, I meant after that. | 07:39 |
| tjaalton | yeah, sure | 07:39 |
| tjaalton | I'll do those next | 07:40 |
| wgrant | Great - once you've done those I'll do my bit. | 07:41 |
| wgrant | Do you know of any existing efforts to give g-c-c proper device-specific property support? I might consider working on that for Jaunty if nobody else can be bothered. | 07:49 |
| tjaalton | you'd have to ask gnome upstream about it.. or just declare that you're doing it :) | 07:53 |
| tjaalton | xinput done | 07:59 |
| tjaalton | Ng: you had problems with the synaptics settings being lost after resume? could you check the logfile if there's something new | 08:18 |
| tjaalton | after it happens | 08:18 |
| tjaalton | wgrant: synaptics updated & uploaded | 08:25 |
| wgrant | tjaalton: Excellent, I'll grab it in 9 minutes when LP finishes with it, hopefully. | 08:32 |
| tjaalton | wgrant: ok cool. I'll be around for ~2h before going to see WALL-E, so be quick to poke if there's something missing :) | 08:37 |
| tjaalton | uh, synaptics failed to build | 08:37 |
| wgrant | Urgh. | 08:37 |
| tjaalton | ../../src/synaptics.c:728: error: too many arguments to function 'XIRegisterPropertyHandler' | 08:37 |
| tjaalton | bah | 08:38 |
| seb128 | tjaalton: hey, do you know if anybody is working on fixing xvfb? | 08:38 |
| tjaalton | seb128: hmm, no.. | 08:39 |
| tjaalton | wgrant: ok, see the bug | 08:39 |
| tjaalton | wgrant: in a patch of mine | 08:39 |
| wgrant | tjaalton: I don't see any patches of yours in the bug... | 08:42 |
| tjaalton | wgrant: I mean, that build problem was due to a patch in the synaptics upload :) | 08:42 |
| tjaalton | buggy refresh | 08:43 |
| wgrant | Oh, you mean "ok, I see the bug". Right. | 08:43 |
| tjaalton | um, yes :) | 08:43 |
| tjaalton | wgrant: heh, the failure was due to the xserver being too old.. so I need to bump the build-dep | 09:01 |
| wgrant | tjaalton: Ah, you don't actually need to... | 09:02 |
| wgrant | You probably just started the build before the new xserver was published (*/2)) | 09:02 |
| wgrant | Er, */20 | 09:02 |
| tjaalton | well, it depends on the properties API, so it should be bumped anyway | 09:04 |
| wgrant | True. | 09:04 |
| Ng | tjaalton: it wasn't synaptic settings as such, I disabled my touchpad in the BIOS. It's the xinput settings I'm running for scrollwheelemulation that's being lost across suspend/resume, presumably (as I think you suggested) because the device disappears and re-appears | 09:05 |
| tjaalton | Ng: yes, probably because of that | 09:08 |
| tjaalton | so it'd need g-s-d support | 09:08 |
| Ng | yeah | 09:09 |
| wgrant | Generic property support in g-s-d would be rather useful. | 09:11 |
| Ng | which reminds me, I need to scan my rough idea sketch about a capplet for that stuff to show to tseliot | 09:14 |
| Ng | I reckon it's going to involve a bunch of nasty white/black listing because the xinput API seems to be awfully generic and unhelpful ;) | 09:15 |
| wgrant | Ah, tseliot is looking at implementing it in capplets too? | 09:16 |
| Ng | like every mouse-ish device seems to report having 32 buttons :/ | 09:16 |
| Ng | wgrant: he said he was interested, yeah | 09:17 |
| Ng | I'm starting to lose my conviction that it's actually particularly necessary, unfortunately | 09:17 |
| wgrant | Why? | 09:17 |
| Ng | wgrant: touchpads not withstanding (mine is disabled, so I've not seen what properties they expose yet), it just seems like the options aren't particularly useful in a general use case | 09:18 |
| Ng | the only thing I can think might be handy would be a "help my scrollwheel isn't working, click here and then scroll up" to detect such things (since they're mapped as buttons and figuring out which buttons to put on the Z axis is non-obvious | 09:19 |
| wgrant | Ng: Hmmm... Disabling, middle button emulation, speed... | 09:19 |
| Ng | disabling yeah, but there are tricky aspects to that - I disabled my touchpad in the bios because if I disable it with the existing mouse capplet it also takes out the buttons on the trackpoint, leaving me with no mouse buttons at all | 09:19 |
| wgrant | Erm. | 09:20 |
| wgrant | I doubt it. | 09:20 |
| wgrant | Or does the trackpoint share the device? | 09:20 |
| Ng | I believe they are shared through the same device | 09:20 |
| wgrant | Ah. Stupidity. | 09:20 |
| Ng | I guess it's easy enough to stop people destroying their system with a "click here to confirm these settings otherwise they will revert in 30 seconds" thing, but still | 09:21 |
| Ng | I'm pretty sure most people don't care about middle mouse buttons, and even fewer care about scrollwheel emulation (which is the only bit I particularly care about) | 09:21 |
| wgrant | We could do that, or we could force people to have at least one checked. | 09:22 |
| Ng | yeah I think it should do that | 09:22 |
| Ng | and if you only have an external USB mouse enabled and unplug that, something else should become enabled | 09:22 |
| Ng | the only question is what. I can give you the correct answer for my laptop, but possibly not for some random Toshiba laptop on the desk next to me | 09:22 |
| wgrant | No, we alter the USB spec such that it has a hardware locking feature that doesn't let the device out when it's enabled. Much better solution. | 09:23 |
| Ng | haha :) | 09:23 |
| Ng | the buttons/scrolling thing is particularly distressing though | 09:23 |
| wgrant | Hm? | 09:24 |
| Ng | these days mice come with umpteen buttons and scroll in multiple directions, but afaik there's no way to actually tell what they are | 09:24 |
| Ng | other than asking lots of questions | 09:24 |
| wgrant | Is there really no spec to report them? | 09:25 |
| Ng | I could be wrong, but I don't think so. scroll events are just other buttons | 09:25 |
| wgrant | How do Those Other OSes do it? | 09:25 |
| Ng | drivers | 09:25 |
| wgrant | Scroll events can also be special, can't they? | 09:25 |
| wgrant | Delta-based, or something like that.. | 09:26 |
| wgrant | So you have to install a custom driver? | 09:26 |
| wgrant | I can't say I've ever used a mouse with more than 5 buttons. | 09:26 |
| wgrant | (including scrollwheel) | 09:26 |
| Ng | generally you get a CD with your mouse and that has the software that sits on top of windows' generic mouse drivers and has a configurator for "this button means launch windows explorer, that one means go back a page in IE, etc" | 09:27 |
| wgrant | Ah. So there's no standard UI. | 09:27 |
| wgrant | We must be able to do better than that. | 09:27 |
| wgrant | I'm quite surprised that there's no obvious way to ask the mouse what it does. | 09:28 |
| Ng | I'm curious if there's a way to map back from the devices that X reports to their underlying HAL device | 09:29 |
| Ng | specifically to get the USB ids if there are any | 09:29 |
| Ng | that way there could at least be some kind of database of devices, or hooks for manufacturers to add their own | 09:29 |
| wgrant | I didn't see one. But it would certainly make sense... | 09:29 |
| wgrant | Maybe evdev could set a property. | 09:29 |
| wgrant | As long as we can have immutable properties... | 09:30 |
| Ng | with no disrespect to the authors of this API, it seems kinda like it's a "damn we need something because xorg.conf is going away", not "let's make a great way for people to configure their devices" :/ | 09:30 |
| wgrant | What can you see as missing? | 09:31 |
| Ng | well a link to the HAL device seems like a must | 09:31 |
| wgrant | One would think so. | 09:32 |
| Ng | I'd like to know if the devices do actually expose any real information about how many buttons they have,b because all of the ones I have just say 32 which is clearly nonsense, so that property should probably either return "Unknown" or not exist | 09:32 |
| wgrant | Indeed. | 09:32 |
| Ng | with the disclaimer that I've been probing with xinput(1) more than with the raw API, I don't see a way to set per-device acceleration | 09:34 |
| wgrant | I haven't seen one... but that's not so much an issue with the API. | 09:35 |
| Ng | (which seems like it could be one of the main use cases for this for "ordinary" users (I'm thinking about where you have a touchpad and a usb mouse and high acceleration for the former makes no sense, but is entirely valid for the latter) | 09:35 |
| Ng | true, that's not an API design thing | 09:35 |
| wgrant | My main complaint is that there's no way to transmit floats - but that's more just because an XAtom doesn't exist for such things. | 09:37 |
| wgrant | That could be why there's no acceleration exposed. | 09:37 |
| Ng | can't that be solved with some powers of ten and ints? ;) | 09:37 |
| Ng | I think the two biggest user problems with input devices are "my scroll wheel(s) didn't Just Work" and "I want these extra buttons to do something useful". I don't know how to solve either of those things gracefully, but they should be solved. If that means g-s-t needs to listen for random button events and launch things, so be it | 09:38 |
| wgrant | I'd considered that... maybe some officially-sanctioned fixed-point representation. | 09:38 |
| Ng | gnome already has a capplet which listens for random keyboard events to launch commands | 09:38 |
| wgrant | metacity handles keyboard shortcuts, doesn't it? | 09:39 |
| wgrant | Those commands are fixed, though (something I disagree with). | 09:39 |
| Ng | hrm, yes that was a poor descriptoin, there's a capplet to *configure* something to listen for those events | 09:39 |
| Ng | I think there is value in having fixed ones, but there should be some generic ones too (which compiz supports, via command0-command10) | 09:40 |
| Ng | play/pause ones certainly make sense, since those are actual hardware buttons on a lot of systems now | 09:40 |
| Ng | forward/back seems to be quite common on funkier mice | 09:40 |
| Ng | tseliot: aha, just the person. we were just talking about the horrifying scope of an input device configurator ;) | 09:40 |
| wgrant | tseliot: I was going to implement one, but I hear you also had the idea. | 09:41 |
| tseliot | Ng, wgrant: yep | 09:41 |
| tseliot | wgrant: what are you planning to do? | 09:41 |
| tseliot | or how are you planning to do it? | 09:42 |
| wgrant | tseliot: Hack some more useful per-device XInput property support into at least gnome-mouse-properties and g-s-d. I'd thought a little about the UI, but not a whole lot further yet. | 09:43 |
| wgrant | To what depth are you asking? | 09:44 |
| tseliot | wgrant: I was thinking about using fdi files for each device which the user wants to configure | 09:44 |
| wgrant | Ah, to that depth. I see. | 09:44 |
| wgrant | I was thinking that g-s-d would do it. | 09:44 |
| wgrant | Can we reload fdi files on the fly? | 09:44 |
| Ng | http://mairukipa.tenshu.net/xinput-capplet.pdf was the idea I had (apologies for the awful scan, and PDF format ;) | 09:45 |
| wgrant | And can't they not set XI properties, just normal xorg.conf ones? | 09:45 |
| tseliot | hmm, I wouldn't know about using xorg.conf options in fdi files | 09:45 |
| * tseliot has a look at Ng's link | 09:46 | |
| wgrant | tseliot: /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi looks like it has normalish xorg.conf properties to me. Or is there a tag name that I'm missing? | 09:47 |
| Ng | tseliot: to recap a bit what was said above, basically while sketching that I kinda realised there's not very much useful stuff that can be set at the moment, and there are problems with some of the options (e.g. disable my touchpad and I'll lose the buttons on my trackpoint, so a "click here within 30 seconds to confirm your settings" option seems wise ;) | 09:47 |
| tseliot | wgrant: right, that's a good example | 09:48 |
| tseliot | Ng: yes, it's what I was about to suggest | 09:48 |
| Ng | :) | 09:48 |
| Ng | one other thing... [09:38] < Ng> I think the two biggest user problems with input devices are "my scroll wheel(s) didn't Just Work" and "I want these extra buttons to do something useful". I don't know how to solve either of those things gracefully, but they should be solved. If that means g-s-t needs to listen for random button events and launch things, so be it | 09:49 |
| tseliot | also we cannot predict how many options a device will have available | 09:49 |
| Ng | but I didn't look at touchpads at all, that fdi file suggests they have lots of nice things to configure | 09:49 |
| tseliot | therefore we might want to use a treeview to contain all the options | 09:49 |
| Ng | hmm | 09:50 |
| Ng | that would be the easy option, certainly :) | 09:50 |
| tseliot | I was thinking about calling XInput from Python, unless we want to do the app all in C | 09:50 |
| wgrant | Aren't the capplets entirely C? | 09:50 |
| Ng | would a non-C capplet be accepted by gnome? I got the impression they don't like python | 09:50 |
| tseliot | I would like to make something which can be used separately from GNOME or KDE | 09:51 |
| wgrant | As much as I love Python, it's perfectly doable (and acceptable upstream) in C. | 09:51 |
| tseliot | so that we don't have to rewrite the same thing for KDE | 09:51 |
| tseliot | it's just an idea | 09:51 |
| tseliot | I would like to use my X-Kit to parse and create fdi files | 09:52 |
| tseliot | but X-Kit is written in Python | 09:52 |
| tseliot | or we can do it all in C | 09:52 |
| wgrant | It seems a but odd to do that when we've just got nice shiny XInput property support. | 09:52 |
| wgrant | *a bit | 09:52 |
| tseliot | and then I will port it to KDE | 09:52 |
| tseliot | yes, I know | 09:52 |
| tseliot | are you guys going to the next UDS? | 09:53 |
| * wgrant is hoping too... but doubts his application will be accepted. | 09:53 | |
| wgrant | s/too/to/ | 09:53 |
| Ng | I will be at UDS, but to work, so I can't really attend any sessions | 09:54 |
| tseliot | well, I applied for sponsorship too, so maybe we can meet there and talk about this | 09:54 |
| Ng | so my discussions will be limited to lunchtimes and dinner/beer ain the evenings ;) | 09:54 |
| Ng | I should be able to participate in fosscamp though, since our technical involvement with that is basically zero | 09:55 |
| tseliot | Ng: who do you work for? | 09:55 |
| wgrant | Sponsored people aren't at FOSScamp, are they? | 09:55 |
| Ng | tseliot: Canonical | 09:55 |
| tseliot | ah, ok | 09:55 |
| Ng | I'm a sysadmin, and some of us go to UDS to provide the SIP/icecast hookups :) | 09:55 |
| Ng | wgrant: dunno :/ | 09:56 |
| wgrant | How is the area that you use in the Google campus for VoIP? I forget - but most of the other venues are shocking. | 09:56 |
| Ng | wgrant: we're in a new area of google this time, so that's unknown at present | 09:57 |
| Ng | it's a really hard problem, unfortunately | 09:57 |
| Ng | we have a polycom conference phone on each desk, with extension microphones on larger desks, but even then the acoustics of the rooms generally lend themselves very badly to a large group of people being recorded | 09:57 |
| Ng | (and really big desks work very badly, because you end up with three conversations at each end of the table, all of which are equal volume on the voip stream, making remote participation basically impossible :( | 09:58 |
| wgrant | The icecasts are usable in most cases (except for some really bad situations, but they're fortunately rare), and VoIP works well between VoIP participants... but VoIP-to-room has only been usable in three or four sessions for me. | 09:59 |
| Ng | yeah, I think we're going to discourage the remote SIP participation and push icecast and a per-track IRC channel (either someone in the session will watch that, or it'll be projected on the wall, hardware willing) | 10:00 |
| Ng | there may also be some other surprise experiments, hardware/google willing :) | 10:01 |
| wgrant | Heh. | 10:01 |
| tseliot | seb128: calling synaptic from the gnome-control-panel requires a text file containing something like "screen-resolution-extra\tinstall\n". Can I add the file to say, /usr/share/gnome-control-center/, or shall I make a temporary file (thus risking to overwrite an already existing temp file) and pass it to Synaptic? | 10:09 |
| seb128 | tseliot: why does it need a text file? | 10:09 |
| seb128 | tseliot: can't you use a *char which has the string? | 10:10 |
| tseliot | no, I can't pass it a string | 10:10 |
| tseliot | mvo knows why | 10:10 |
| seb128 | we don't create temporary files for other softwares who call synaptic | 10:11 |
| wgrant | tseliot: Erm, how would it overwrite an existing temp file? | 10:12 |
| tseliot | seb128: --set-selections-file is what allows you to pass a file to synaptic | 10:12 |
| wgrant | If you're doing it that way, it is a security flaw and you're doing it wrong. | 10:12 |
| mvo | seb128: we do (unfortunately) because gksu does not let us use stdin in synaptic (it closes that fd), so t control it it needs a file | 10:13 |
| tseliot | wgrant: it can happen that a temp file with the same name exists. And I know that there is a right way to use temp files | 10:13 |
| mvo | tseliot: check debian/patches/80_gst-packages-common.patch from the gnome-system-tools package | 10:14 |
| tseliot | mvo: ok, thanks | 10:14 |
| mvo | tseliot: it has code that you can use (like create_temp_file that does the right thing etc) | 10:14 |
| tseliot | mvo: great, it's what I was looking for | 10:17 |
| mvo | excellent! | 10:17 |
| === Ng_ is now known as Ng | ||
| l33 | hi | 13:44 |
| l33 | https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-mutouch/+bug/275650 | 13:44 |
| ubottu | Launchpad bug 275650 in xserver-xorg-input-mutouch "mutouch driver in hardy is Y axis Inverted" [Undecided,New] | 13:44 |
| jcristau | tjaalton, bryce: i uploaded x-x-i-mutouch today, fixes lp bug 275650, fwiw | 17:26 |
| ubottu | Launchpad bug 275650 in xserver-xorg-input-mutouch "mutouch driver in hardy is Y axis Inverted" [Undecided,New] https://launchpad.net/bugs/275650 | 17:26 |
| jcristau | well, should fix, anyway :) | 17:26 |
| bryce | jcristau: ah excellent, I'll take a look | 17:26 |
| bryce | jcristau: the package isn't at ftp://ftp.debian.org/debian/pool/main/x/xserver-xorg-input-mutouch/ yet; is there I place it's held I can grab it from? | 17:37 |
| jcristau | http://incoming.debian.org/ | 17:38 |
| bryce | thanks | 17:38 |
| bryce | sync request filed - #275650 | 18:11 |
| solarion | wgrant: there's apparently a driver in existance | 18:54 |
| solarion | wgrant: the last update (besides mine) on bug 123775 is saying Alpha5 is out and it might work now | 18:55 |
| ubottu | Launchpad bug 123775 in linux "Elantech touchpad is incorrectly recogonised as a "ImPS/2 Logitech Wheel Mouse"" [Unknown,Confirmed] https://launchpad.net/bugs/123775 | 18:55 |
| solarion | which it doesn't | 18:55 |
| solarion | I guess the question is, how can I move things along?' | 18:55 |
| solarion | the tap-to-click behavior is driving me crazy | 18:55 |
| bryce | hi tormod | 19:17 |
| tormod | hi bryce | 19:20 |
| mnemo | what prefix should I use if I install the xorg intel driver on ubuntu? | 19:34 |
| mnemo | just doing plain "sudo make install" doesnt seem to work | 19:34 |
| bryce | from debian/rules: ../configure --prefix=/usr [...] | 19:37 |
| mnemo | bryce: hmm, what is debian/rules used for exactly? is it a build script? i know how to find the file and I see the prefix in there but I wonder what that file is used for? is it available for all debian packages? | 19:41 |
| bryce | yes it is a build script for generating .deb files | 19:41 |
| bryce | each debian package has a debian/rules file | 19:42 |
| mnemo | oh excellent, this is very useful info for me | 19:42 |
| mnemo | thanks bryce | 19:42 |
| bryce | standby, I can give you a link with more info | 19:42 |
| bryce | mnemo: this seems to be a fairly friendly tutorial on building debian packages in ubuntu: http://women.debian.org/wiki/English/BuildingTutorial | 19:44 |
| bryce | a lot more info is available on this from https://wiki.ubuntu.com/PackagingGuide/ if you'd like to learn it in more depth | 19:47 |
| mnemo | thanks | 19:51 |
| mnemo | bryce: im reading the packaging howto now, and I got a question (if you got time)... why do people use "fakeroot"? i mean, why does a program required me to lie to it about being root when the operation actual can run successfully without root? | 20:02 |
| bryce | I don't know exactly, but all packaging systems I've used have required running as root | 20:03 |
| mnemo | strange, sounds like a bug to me :D i'll try to google for the answer later | 20:05 |
| bryce | perhaps non-root doesn't have sufficient access to the packaging system internals | 20:06 |
| mnemo | but fakeroot has? | 20:06 |
| bryce | actually, it is possible to build packages with non-root via debuild | 20:06 |
| bryce | debuild -i -uc -us $pkg.dsc | 20:07 |
| bryce | but that may use fakeroot internally, not sure | 20:07 |
| mnemo | wait, yeah maybe the same binary is used to read and write some package data and to write the package data root might be required and instead of elevating in the middle of the program they decided that the program always will require root | 20:07 |
| tjaalton | bryce: apart from evdev, all the drivers include their own fdi file | 22:00 |
| tjaalton | bryce: I'll reply to the wacom thread tomorrow :) | 22:00 |
| bryce | tjaalton: ah ok | 22:00 |
| tjaalton | there seems to be some misinformation that needs to be corrected | 22:01 |
| wgrant | solarion: The driver isn't in Linus' tree, so this isn't an X problem. | 23:04 |
| wgrant | It's not in Linus' kernel, so it's not in our kernel by default, so it's a kernel problem. | 23:04 |
| pwnguin | which wacom thread? | 23:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!