Hey all, two quick questions/points of interest here.
First off, Benson awesome work on this so far... regarding this point:
I ran into the same trouble with my udev rules for the wired networking package; the problem stems from the fact that the moment you take the device out of host mode it no longer fires USB events, so any devices that were created on the system by USB connect events never get removed because the "remove events" never get fired; removing the device from the USB connector first leaves the tablet in host mode, letting the events fire properly. I'm trying to get work around using DBUS events going (a dbus event gets fired when the tablet goes in or out of host mode, so it should be possible to trigger a global USB "remove" event at that point to resolve our problems) but haven't had a lot of time to work on it recently.

I thought it might be something like that. Glad you're working on doing things the right way. My next hack is currently going through testing, I should be posting it real soon...

Allright, here's the new version. You no longer need a .evrouterrc; it makes that on-the-fly (under a different name). If you do have one, it will be included in the created file, so if you use evrouter to rebind keys or touchscreen events, that'll still work.

This probably won't work with two mice hooked up. If it does, only one will work. If someone wants to post patches for multiple mice, that's great, but it's too much hassle for me, and I couldn't test it anyway...

By the way, reason I didn't warn anyone about the unplugging issue: I'm hardly aware of it, because everytime I unplug the mouse, it's to plug it back into my desktop. So I'm leaving the adapter in the N800, and going back and forth. I'll be even more grateful for your (presumed) fix when I get around to buying a little mouse for the N800.

Has anyone encoutered the disappearing pointer? I haven't been able to pinpoint what event causes it.

I had originally just commented out the line in index.theme and all seemed fine. Then, the pointer would disappear at some point. I decided to change the pointer theme to the neutral one from http://www.xaprb.com/blog/2006/04/24...l-x11-cursors/. Same problem.

The weird thing is that I can open some apps and the pointer will appear within the window of that app. If I move out to the status bar for example, the pointer disappears.

Any thought?

Thanks in advance,

Mike

Well I managed to come up with a bit of a half-way solution for the USB OTG removal problem that we were talking about earlier. It's "half way" because it works, and it's somewhat right, but it's not exactly how it should be; the primary problem is that when the device switches from OTG host mode to device mode it simply seems to shutdown the USB interface instead of causing USB disconnects to occur. It's a kernel level bug/issue/problem that I'm not even sure the kernel people are aware of, let alone trying to fix. Now I'd originally thought "hey, alright, just find a way to manually trigger those USB disconnect messages"... well, yea turns out that's a kernel-level thing too, so without basically writing a mini-version of the kernel to udev/device interface there really wasn't a way to do that. So, instead what I've done is the next best thing: using Graham Cobb's dbus-messages package (which I had to fix up so that you could actually install it since Graham seems to have mis-packaged it somehow) I set things up so that the system listens to the DBUS to find out when the tablet changes OTG modes; it calls a script at each change which checks to see which mode the tablet is now in, and if it's just gone back into device mode then it manually runs through all of the udev rules, searching for any that specify a subsystems="usb", action="remove", and have a run+ attribute; it then manually runs each of the run+'s, effectively having the same result as if the udev rules had been executed properly by udev itself.

Now, the one catch is that it won't actually clean up sysfs or any of the devices that the kernel created when the USB device(s) were first connected, but hey, that's acceptable as far as I'm concerned.

I've updated the networking package to utilize this new way of doing things, and it works like a charm. For the mouse package (when the bugs get sorted and we want to package things up) we can do it the same way, and just establish udev rules that will a) fire up the mouse script when a mouse is attached and B) rather than listening for the device to disappear as you currently do, just setup a second udev rule that says "kill the mouse script when the USB mouse is disconnected"; should solve the connect/disconnect issue.

Thoughts?

Thanks,
-Rob

If it looks like a kernel bug, some kernel person should be notified...

But it sounds like a good short-term fix..

Are their plans to make a deb for mouse support? it would certainly improve quake game play

I don't know that this will help quake much. I think the way it's being fudged in will actually cause problems for things that want relative motion.

I don't know the first thing about packaging for debian, but I believe Rob's looking to make that happen at some point. But it's pretty easy to drop in the current setup, I think. More testing and suggestions before it gets packaged are helpful.

Alright some progress has been made here... things are definately not ideal, but it's a half-decent hack that works for general purposes. I've taken the latest version of Benson's script along with the original mouse_poll and evrouter ports, wrapped it all up in a nice little deb package and thrown in a few udev rules for good measure.

The results:
Once the package is installed you can plug in your mouse at any point. Any NEW window/application you open (i.e. open the browser, notes, etc) will have a visible cursor and the mouse should operate as expected within that application. Once you're done disconnect the mouse and any NEW window/applications that you open will be without a visible cursor again.
Now, if you want to go full out, connect the mouse, wait for the "no file system found" dialog, then power cycle the tablet with the mouse connected. When the Tablet reboots you should have a normal cursor for the tablet and all subsequent applications. When you're done, simply unplug the mouse as usual, and next time you reboot the tablet the cursor will go away.

A few important things/shortcommings to note here:

1) The mouse counts as an input device, so the tablet seems to automatically disable the on-screen keyboard/thumb keyboard. I don't know how to stop/get around this (and ideas?). So probably a good idea to use a hub and hookup a usb keyboard as well ;o)
2) Related to that... I have created the dbus-scripts package as a solution to the "remove the OTG adapter" instead of "disconnect the USB device" problem, but related to #1, the tablet doesn't recognize that the input device is no longer present, so the keyboard/input never returns. THEREFORE make sure you always disconnect the mouse from the USB BEFORE disconnecting the OTG/taking the tablet out of host mode. (Failure to do so will mean no virtual keyboard until you either do this properly or restart the tablet).
3) I have no idea why but for some reason the mouse just doesn't work as expected on some things... It works for most of the main interface, but not the "applications menu" button?... no idea why...
4) I have no idea how this will react if you have a custom theme installed... theoretically it should work in the same way, but I haven't tested it...

And if you're after better support/proper usage features for this, get bugging the Maemo guys about putting proper support into the next kernel/system release for this...

DBUS-Scripts
http://www.electronicproductonline.c....0.3_armel.deb

USB Mouse:
http://www.electronicproductonline.c..._0.1_armel.deb

Thanks,
-Rob

VERY cool man! This is my first try at using a mouse on the n800, and it works beautifully! Not only that, it is very easy to install compared to other solutions I`ve seen on this board ---- just install the .debs. To your point, it is not perfect, but it gets the job done --- it in fact compliments my iGo keyboard very well.

Aside from what you mentioned above, the other oddity I found is that the mouse pointer loses focus once i click into input fields. For example, I am typing in the reply field now, and even though the mouse is viewable, clicking on anything outside of it will not work until I tap on the screen with my stylus. I hope that made sense.

In any case, thank you very much. Can`t wait to see how future revisions work out.