One reason the mouse doesn't work in some spots:
On some elements, the click event seems either ignored, or at least only processed with the pressure data. No pressure data, no action. This seems to be the issue with the Applications menu, because it used to be stylus/finger sensing, and also to all osso text fields, because they are trying to sense which keyboard. Sol'n? I guess someone needs to go file a bug report...

Some information exists regarding synergy or VNC (forgot which) and doing something to the xserver to make it have no pressure data; then it falls back to click-only behavior. But I think you had to reboot to change it. I'll go look... Here we go, you do need to restart the server for that (same as to get cursors on every app).

/etc/init.d/x-server only has start and stop options; we could extend that perhaps, so we don't have to do a full reboot for either of these?

But a server restart still closes all apps, so maybe it'd be safer to just leave it with rebooting. Changing the x-server args via udev also seems wise, unless some people would actually reboot their tablet/restart x every time they disconnect the mouse.

Now that it's all deb'd up, can someone with KDE (I know you're reading this) try it out? I know it works with rdesktop and VNC rather well, but I haven't taken the plunge and installed a non-hildon setup yet. I'd like to hear back if it's working and which things are broken. (QT finally supports wheel mouse events, doesn't it? then you should probably map the wheel to buttons 4 and 5 as discussed above.) I think this should go well in KDE, since nothing there should be looking at Xinput...

I have installed the usbmouse deb and am running PB's KDE and HOORAY!! I now have mouse support too. Am working with a wireless keyboard and mouse now on it. . I am still going through all apps with it to test. So far looks good. This is great!! Thanks so much for your work. I have been using synergy when working with my N800 and desktops at work and now this will make it even better when its standing alone.

exciting progress! exactly what i was waiting for. would this work with a bt mouse (please post model if you've tried)

[quote}On some elements, the click event seems either ignored, or at least only processed with the pressure data[/quote]

Ahhh alright that makes sense then, I knew it was something strange like that. Yea, it's probably not really worth messing around with the X-server settings; biggest reason being if you do something wrong/for some reason the x-server launch command gets messed up you've essentially bricked your tablet and will need to re-flash the entire thing (short of modding up your own serial-based console...). So long and short of it is that it's not worth messing with; if you want that, add it manually as Benson pointed out in the link, and be aware of the risks you're taking.

Oh and on the non-rebooting thing... yea I looked into that as well; theoretically you should be able to restart the x-server without actually power cycling the tablet, but if you look at it it's actually quite silly and difficult. First of all the x-server is launched through another app (the name of which I presently forget and am too lazy to go and lookup) that essentially says "when x-server quits issue the reboot command", so you'd have to circumvent that (not difficult, but one more thing to do). Secondly, when you look at the boot order... x-server is one of the first things to load, so since most other init files are adding applications and features to x-server it really doesn't make sense to restart the x-server without reloading all of those init scripts... which at the end of the day means for all the work, you are basically simulating a reboot except for the initial hardware detection; is it possible? yup, is it worth actually doing compared to just rebooting? probably not...

In terms of a BT mouse, the only difference is that the udev rules are setup to fire for USB events right now (I don't have a BT mouse to test with, so I don't even know if udev gets fired when you pair BT devices or not), so you need to make sure you manually launch the start and stop scripts after pairing the mouse.
To start:
open xterm, gainroot, and launch /usr/sbin/mouseStart.sh

when you're done, go back to xterm as root and launch /usr/sbin/stopMouse.sh

Glad to hear that it works properly in KDE though, that's neat! One step closer to a mini-laptop...

Thanks,
-Rob

what is the advantage of the mouse over the touch screen?
does it provide better scrolling on web pages or any other benefit?

The cursor is very quick in most apps but it a bit erratic in duke3d and quake. Quake worked perfectly, i mean perfectly!, for a while then only allowed up down aiming and ignored left-right movement. duke3d was opposite it responded great to left-right but not up-down. Mouse buttons worked in quake but only scroll button worked in duke.

I notice a extra drain on battery life even though i'm using a powered hub. is there a way to prevent the n800 from giving power to the mouse?

still really awesome! you should submit the deb to maemo.org so that more people realize it works.

I expect the ignoring motion in one direction symptom reflects the mouse having gotten stuck against one side of the screen.

WRT battery life, I don't think you can do anything about it, short of rewiring your adapter with no connection to +5; even then it'd hurt battery life just using the signal lines. I wouldn't use USB much on batteries...

jolouis,

Great work.

Mouse works!!
I also did notice that the mouse disappears when you put it over a menu tab that takes you to another location. Also any chance of getting mouse to work with your ethernet wire setup? I always want more especially when it's good and free! Nice work Benson also. lol. Dan

This is so awesome! I cant wait to buya mouse any particular brand/model you recommed? Do I need an adapter?

Nokian111, you might use a mouse for any of several reasons:

• Scroll wheel
• More buttons (Can be bound to useful actions, e.g. left-hand buttons for games)
• More precision than even the stylus
• Because you're using some non-touch based environment (like KDE or Windows) that expects more buttons and/or mouse motion without buttons down
• Just 'cause it's cool (like me )

I see no reason it wouldn't work with a hub, mouse, and NIC.

Regarding particular choice of rodents, it doesn't much matter -- anything up to 3 buttons + 1 scroll axis (typical wheel mouse) should work, and anything more complex will likely work that far. If you want more buttons to work, it should be trivial to make them work. The above applies to USB mice only, of course; BT should work except pairing difficulties, and mine just arrived an hour ago, so I can't recommend for or against it (yet...) but I expect some serious variation between brands for pairing, just like keyboards. I think if it pairs, it works.