Re: mouseemu 0.15-2 broken with kernel 2.6.16.*?
can someone confirm, that mouseemu 0.15-2 is broken with kernel = 2.6.16? I had it successfully running with 2.6.15.4 and switched to the 2.6.16 series to get Airport Extreme support (1). Now mouseemu stopped working. Should not happen - the changes that went into -3 fixed rather long standing bugs WRT device scanning and handling of disconnected devices. Try updating udev, maybe the problem is related to udev. And please check /sys/class/input* and see if the corresponding event* devices are all present in /dev/input/. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu
On Mon, 27 Mar 2006 14:23:11 +0200 (CEST), Michael Schmitz [EMAIL PROTECTED] said: The state of the modifier key is kept by the X server, so you need to send the modifier before you send a regular key event (disregarding mouse events for a moment here). We could postpone the modifier event until we know what other event follows, but that's equally messy. I kind-of worked out a state machine to do this sort of thing; the result was horrible. Later on today I will have at look at the behaviour of Apple X11, and check out what events it is generating. Right, they must have solved this some way already. Yep, it just seems to send a modifier-up, button-click, modifier-down when the mouse is clicked. Should not really happen, because mouseemu intercepts all input events hopefully, and hence can ensure they get sent in the correct order. Meaning you cannot sneak a key event in between the mod up, mouse down, mod down sequence. IIRC X doesn't mind if the modifier state changes while a button is kept down. Either way, there's limits to what extent you can emulate mouse buttons using modifier keys. I'll cook up some experimental hack for you to test. That would be really cool! -- http://www.fastmail.fm - Does exactly what it says on the tin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu
Hi Michael, On Sat, 25 Mar 2006 16:55:21 +0100 (CET), Michael Schmitz [EMAIL PROTECTED] said: I am now getting button 2 and button 3 events sent, but the modifiers are getting sent too. That's per design, and was done to fix bug #304328. Maybe the fix broke your case, though. After some consideration, I believe that that this new behaviour, where the modifier is sent as well as the emulated mouse button, is the cleanest and most X-like way of doing it. Remove the patch to pass though modifier events, then. Or at least block the modifer events that were used to generate the mouse events (see below). You lose the option to generate mouse events with modifers (but then, you cannot distinguish between a mouse event with and without modifier anyway, if you chose to use a modifier with the mouse keycode). I looked at the mouseemu source code, and spent some time reading various X documentation. Based on my limited understanding of X, it seems there is no clean way of mulitplexing modifier keys to fulfil both tasks (mouse button emulation, but normal modifier behviour for other keypresses). I imagine that these issues are already well-known. Later on today I will have at look at the behaviour of Apple X11, and check out what events it is generating. First of all, don't use modifier keys tha you need to see in other apps with mouse emulation. Second, you can change the passthrough code to only pass a modifier event if it does not belong to a emulation key - this will get quite messy though. You'll need to delay the modifier for a short time to see if a mouse key follows (or send a modifier up, mouse button, modifier down sequence). I think that out of all the workarounds, the suggestion to send a modifier up, mouse button down sequence would be the best. But still, like you suggest, it will get quite messy. I can imagine a few cases in which this will lead to confusing and unintended behaviours. Thank you, Michael, you for all your help and advice. -- http://www.fastmail.fm - Email service worth paying for. Try it for free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu
I am now getting button 2 and button 3 events sent, but the modifiers are getting sent too. That's per design, and was done to fix bug #304328. Maybe the fix broke your case, though. After some consideration, I believe that that this new behaviour, where the modifier is sent as well as the emulated mouse button, is the cleanest and most X-like way of doing it. Yep; I've had a closer look and there's little chance to do it any other way. I looked at the mouseemu source code, and spent some time reading various X documentation. Based on my limited understanding of X, it seems there is no clean way of mulitplexing modifier keys to fulfil both tasks (mouse button emulation, but normal modifier behviour for other keypresses). I imagine that these issues are already well-known. The state of the modifier key is kept by the X server, so you need to send the modifier before you send a regular key event (disregarding mouse events for a moment here). We could postpone the modifier event until we know what other event follows, but that's equally messy. Later on today I will have at look at the behaviour of Apple X11, and check out what events it is generating. Right, they must have solved this some way already. I think that out of all the workarounds, the suggestion to send a modifier up, mouse button down sequence would be the best. But still, like you suggest, it will get quite messy. I can imagine a few cases in which this will lead to confusing and unintended behaviours. Should not really happen, because mouseemu intercepts all input events hopefully, and hence can ensure they get sent in the correct order. Meaning you cannot sneak a key event in between the mod up, mouse down, mod down sequence. IIRC X doesn't mind if the modifier state changes while a button is kept down. Either way, there's limits to what extent you can emulate mouse buttons using modifier keys. I'll cook up some experimental hack for you to test. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu
and then restarted the daemon. This kind-of works, in that I am now getting button 2 and button 3 events sent, but the modifiers are getting sent too. For example, xev tells me that Super_L is getting sent as well as button 3 (see below). That's per design, and was done to fix bug #304328. Maybe the fix broke your case, though. So middle and right clicks do the right thing for applications which ignore the modifiers. But for applications which take notice of the modifiers, for example, xterm or emacs, things don't work right. For example, middle clicking in xterm doesn't paste, because (I presume) it's seeing Alt_L + button 2, instead of only button 2. I want my applications to see button 2 and button 3, without seeing the modifiers that were used to simulate them. Remove the patch to pass though modifier events, then. Or at least block the modifer events that were used to generate the mouse events (see below). You lose the option to generate mouse events with modifers (but then, you cannot distinguish between a mouse event with and without modifier anyway, if you chose to use a modifier with the mouse keycode). Does anybody have any ideas as to how I might be able to do this? First of all, don't use modifier keys tha you need to see in other apps with mouse emulation. Second, you can change the passthrough code to only pass a modifier event if it does not belong to a emulation key - this will get quite messy though. You'll need to delay the modifier for a short time to see if a mouse key follows (or send a modifier up, mouse button, modifier down sequence). Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu on powerbook5,8
On Sun, 2006-03-05 at 23:06 +0100, Mich Lanners wrote: mouseemu needs to handle disappearing event devices gracefully. Does this seem OK? Yes. The same will happen if you unplug a USB mouse :) johannes signature.asc Description: This is a digitally signed message part
Re: mouseemu 0.15 not working at all? [SOLVED]
hy there, i just wanted to present the solution to my not-working-mouseemu-0.15. in fact i completely misinterpreted its manpage. with ... # mouseemu -right x y ... i thought that i get a right-click EITHER by pressing x+mousebutton OR by pressing y. actually it is way more simple: # mouseemu -right x y means of course that you get the right-click by pressing x AND y. in my case (powerbook) i want mouseemu -right 29 272 where 29 is the left ctrl-key and 272 is the (single) mousebutton available. i guess i got somewhat confused with CONFIG_MAC_EMUMOUSEBTN=y available in the kernel and pbbuttonsd. ok, sorry for bothering. and thanks to the other michael for being so patient :-) michael -- Feel free mit GMX FreeMail! Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu 0.15 not working at all?
before moussemu starts (and after it has been terminated) ls /dev/input shows event4, event5, mice, mouse1 and uinput That's odd - why does the event device list start with event4? Which devices do event4 and event5 correspond to (see /sys/class/input)? with mouseemu -right 29 0 -device /dev/input/uinput a ls /dev/input shows event4, event5, event6, event7, mice, mouse1, mouse2 and uinput. cat'ing through these files shows that only mice is getting any events That's odd - event4 and event5 should get the mouse and keyboard events if that's what they are 'connected' to. I begin to suspect event4 and event5 correspond to USB, and 0-3 are the ADB devices which simply do not show up. Try to create the device nodes manually (mknod /dev/input/event0 c 13 64 and so on). If that does not help, try a reasonable kernel. The only thing that's missing (from my POV) is the kernel mouse button emulation device. Which should not really matter. which is true: i had a configuration with CONFIG_MAC_EMUMOUSEBTN enabled which gave me p.ex. the right mousebutton by pressing f12. but that's not what i wanted and the mouseemu-problem wasn't solved by that. The key code can be configured, but control-click isn't possible that way. if no one has other ideas, i will look up the source code but i don't know if i can master this ;-) See the above suggestions: create the missing event devices by hand, and try a recent kernel. Debugging mouseemu should be rather easy, but if the events are never passed on by the kernel, debugging mouseemu won't help any. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu 0.15 not working at all?
connected device: mouseemu virtual keyboard, NULL connected device: mouseemu virtual mouse, NULL afterwards (mouseemu still running) i have again the adb3:301/input lines for mouse-movement. Seems like mouseemu does not in fact manage to open the other event devices, or fails to grab the events for exclusive use. mouseemu uses /dev/input/event%d so make sure these are present before mouseemu starts (ISTR they were present on your system, but double check). And check they actually deliver events (just cat /dev/input/event*) - if that all still works out, add some debug code to mouseemu.c:scan_for_devs() to see what precisely goes wrong there. before moussemu starts (and after it has been terminated) ls /dev/input shows event4, event5, mice, mouse1 and uinput with mouseemu -right 29 0 -device /dev/input/uinput a ls /dev/input shows event4, event5, event6, event7, mice, mouse1, mouse2 and uinput. cat'ing through these files shows that only mice is getting any events when the mousecursor is moved or any key is pressed (no matter if mouseemu is started or not). but this output is not human readable (some weird characters) and afterwards my prompt is messed up with these characters. cat /dev/input/uinput gives by the way a Kein passendes Gerät gefunden (no suitable devices found). up the /var/log/debug log from beginning of the last startup of my mac. the first evbug entries are: evbug.c: connected device: adb keyboard, adb2:2.c4/input evbug.c: connected device: adb powerbook buttons, adb7:7.1f/input evbug.c: connected device: adb mouse, adb3:3.01/input (...) evbug.c: connected device: dmasound beeper, macio/input0 (...) evbug.c: connected device: hid 05ac:1000, usb-001:10:1a.0-1/input0 evbug.c: connected device: hid 05ac:1000, usb-001:10:1a.0-1/input1 after that mainly the event-entries mentioned earlier are logged The only thing that's missing (from my POV) is the kernel mouse button emulation device. Which should not really matter. which is true: i had a configuration with CONFIG_MAC_EMUMOUSEBTN enabled which gave me p.ex. the right mousebutton by pressing f12. but that's not what i wanted and the mouseemu-problem wasn't solved by that. if no one has other ideas, i will look up the source code but i don't know if i can master this ;-) michael -- DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert: GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu 0.15 not working at all?
no output indeed. so do i understand you correctly? because of that, some other application steals the events which therefor cannot be processed by mouseemu? any ideas which applications that might be? No, that's not what I said. Usually mouseemu 'steals' the events. mouseemu not getting any events at all does point to the kernel as likely culprit, IMHO. Regarding other apps receiving events, see my suggestion to search /proc for any occurrences of 'event' files. Any process opening some event device will have a file /proc/pid/fd/event%d showing in /proc. To see which events are processed by the kernel, load the evbug module and watch /var/log/debug Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu 0.15 not working at all?
no output indeed. so do i understand you correctly? because of that, some other application steals the events which therefor cannot be processed by mouseemu? any ideas which applications that might be? No, that's not what I said. Usually mouseemu 'steals' the events. mouseemu not getting any events at all does point to the kernel as likely culprit, IMHO. so what should be activated in the kernel in addition to CONFIG_INPUT_UINPUT=[y|m] (the only option i found that was necessary). Regarding other apps receiving events, see my suggestion to search /proc for any occurrences of 'event' files. Any process opening some event device will have a file /proc/pid/fd/event%d showing in /proc. ls /proc/*/fd does not show any event%d files only symlinks in earlier postings in debian-powerpc, i have found something like /proc/input/devices. the input directory does not exist on my mac. To see which events are processed by the kernel, load the evbug module and watch /var/log/debug ok, moving the mouse produces something like ... event. dev: adb3:3.01/input, type: 2, code: 1, value -1 mouse-click ... event. dev: adb3:3.01/input, type: 1, code: 272, value 0 event. dev: adb3:3.01/input, type: 0, code: 0, value 0 pressing ctrl ... event. dev: adb2:2.c4/input, type: 1, code: 29, value 0 event. dev: adb3:3.01/input, type: 0, code: 0, value 0 michael -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu 0.15 not working at all?
No, that's not what I said. Usually mouseemu 'steals' the events. mouseemu not getting any events at all does point to the kernel as likely culprit, IMHO. so what should be activated in the kernel in addition to CONFIG_INPUT_UINPUT=[y|m] (the only option i found that was necessary). CONFIG_INPUT_EVDEV, obviously. Regarding other apps receiving events, see my suggestion to search /proc for any occurrences of 'event' files. Any process opening some event device will have a file /proc/pid/fd/event%d showing in /proc. ls /proc/*/fd does not show any event%d files only symlinks Just great. If you stop for a moment and examine any arbitrary process's fd directory you'll notice it's always symlinks. s/file/entry/ above if you like. Now which are the processes that have symlinks containing 'event' in their fd set? in earlier postings in debian-powerpc, i have found something like /proc/input/devices. the input directory does not exist on my mac. To see which events are processed by the kernel, load the evbug module and watch /var/log/debug ok, moving the mouse produces something like ... event. dev: adb3:3.01/input, type: 2, code: 1, value -1 So far so good. In theory, the output should change somewhat after starting mouseemu - all the adb3:3.01/input stuff should be replaced by NULL, for instance (that's mouseemu's virtual keyboard and mouse injecting the events back into the system). (Note that you can figure out the event codes for the emulation keys from the evbug output when mouseemu is not running - just to double check your configuration.) If the output does not change after starting mouseemu, something in the device open code of mouseemu fails (I doubt it, though). Look through the debug log to find the spot where the evbug module loads - it reports all registered event devices with name and device name. You should find all keyboard, mouse and button devices listed there, plus a few odd ones. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu 0.15 not working at all?
No, that's not what I said. Usually mouseemu 'steals' the events. mouseemu not getting any events at all does point to the kernel as likely culprit, IMHO. so what should be activated in the kernel in addition to CONFIG_INPUT_UINPUT=[y|m] (the only option i found that was necessary). CONFIG_INPUT_EVDEV, obviously. no. i just looked it up. that's also activated. Regarding other apps receiving events, see my suggestion to search /proc for any occurrences of 'event' files. Any process opening some event device will have a file /proc/pid/fd/event%d showing in /proc. ls /proc/*/fd does not show any event%d files only symlinks Just great. If you stop for a moment and examine any arbitrary process's fd directory you'll notice it's always symlinks. s/file/entry/ above if you like. Now which are the processes that have symlinks containing 'event' in their fd set? again: none. there is not entry/file that contains the string 'event' in earlier postings in debian-powerpc, i have found something like /proc/input/devices. the input directory does not exist on my mac. To see which events are processed by the kernel, load the evbug module and watch /var/log/debug ok, moving the mouse produces something like ... event. dev: adb3:3.01/input, type: 2, code: 1, value -1 So far so good. In theory, the output should change somewhat after starting mouseemu - all the adb3:3.01/input stuff should be replaced by NULL, for instance (that's mouseemu's virtual keyboard and mouse injecting the events back into the system). jup. /var/log/debug logs exactly two different lines: connected device: mouseemu virtual keyboard, NULL connected device: mouseemu virtual mouse, NULL afterwards (mouseemu still running) i have again the adb3:301/input lines for mouse-movement. (...) Look through the debug log to find the spot where the evbug module loads - it reports all registered event devices with name and device name. You should find all keyboard, mouse and button devices listed there, plus a few odd ones. i have compiled evbug directly into the kernel, so no module. i have looked up the /var/log/debug log from beginning of the last startup of my mac. the first evbug entries are: evbug.c: connected device: adb keyboard, adb2:2.c4/input evbug.c: connected device: adb powerbook buttons, adb7:7.1f/input evbug.c: connected device: adb mouse, adb3:3.01/input (...) evbug.c: connected device: dmasound beeper, macio/input0 (...) evbug.c: connected device: hid 05ac:1000, usb-001:10:1a.0-1/input0 evbug.c: connected device: hid 05ac:1000, usb-001:10:1a.0-1/input1 after that mainly the event-entries mentioned earlier are logged michael -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu conflicts with ikeyd
My kernel is 2.6.8-powerpc (default in sarge). Any ideas why mouseemu
behaves in such a way?
Well, all of them need to receive events in some way. mouseemu grabs
keyboard and mouse devices for exclusive use (meaning events are not
passed on to other processes) in order to suppress the key events
associated with the mouse button emulation keys. The kernel event
interface does not leave any other option there. Events other than
emulation key events are passed on to other processes via a virtual
keyboard and virtual mouse device.
In some mysterious way, this event passthrough does not always work. 2.6.8
is a bit old, maybe that's part of the problem. devfs/udev may also be
interfering. Order of process startup may matter - mouseemu creates the
virtual devices, so starting that first, making sure the virtual devices
work (e.g. you can still type :-) then starting the others should help.
pbbuttonsd rescans for new input devices if so configured. ikeysd I'll
have to check.
In order to diagnose your setup, we'd need a dump of your
/sys/class/input/ - like this:
ls -lR /sys/class/input/
find /sys/class/input/ -type f -print -exec cat {} \;
(as root).
Doing this once after starting each of the event-eating processes might
help in sorting out which process creates what, and which input device
finally messes it all up. Make sure you have recent versions of pbuttonsd
and ikeysd, of course.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu conflicts with ikeyd
Following up on my own explanations: In some mysterious way, this event passthrough does not always work. 2.6.8 Event passthrough is not even reaching ikeyd - ikeyd explicitly scans for the button device _only_. ikeyd needs to be fixed to search for a virtual keyboard and mouse device _first_, and use that if present. I can cook up a patch if necessary. While we're at it - ikeyd needs to be made aware of udev as well. Regarding ikeyd's functionality - it's all provided by pbbuttonsd. Why bother? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu conflicts with ikeyd
Following up on my own explanations:
Again ...
Event passthrough is not even reaching ikeyd - ikeyd explicitly scans for
the button device _only_. ikeyd needs to be fixed to search for a virtual
keyboard and mouse device _first_, and use that if present. I can cook up
a patch if necessary. While we're at it - ikeyd needs to be made aware of
udev as well.
See attached patch - virtual keyboard device is probed first. ikeyd now
gets to see events on my system. Test and improve, please.
Michael
--- ikeyd.c.org 2006-02-20 18:03:44.0 +0100
+++ ikeyd.c 2006-02-20 18:06:30.0 +0100
@@ -97,6 +97,7 @@
static int check_pmu ();
static void check_pidfile ();
static int find_button_device ();
+static int find_virtual_device ();
static void eject_cdrom ();
static void volume_change (int level);
static void remove_pidfile (int signum);
@@ -180,8 +181,12 @@
exit (EXIT_FAILURE);
}
- /* now search the button device */
- eventfd = find_button_device ();
+ /* now search the virtual event devices */
+ eventfd = find_virtual_device ();
+ if (eventfd 0) {
+/* now search the button device */
+eventfd = find_button_device ();
+ }
/* check the pidfile */
check_pidfile ();
@@ -585,6 +590,94 @@
return eventfd;
} /* »»» */
+/* static int find_virtual_device () ««« */
+static int
+find_virtual_device ()
+{
+ /* the filename of the event interface */
+ char *filename;
+ /* the filedescriptor of the event interface */
+ int eventfd = -1;
+ struct input_id id;
+ char name[256] = UNKNOWN;
+ int i;
+
+ for (i = 0; i 32; i++)
+{
+ filename = malloc (strlen (EVENT_PATH) + 3);
+ sprintf (filename, %s%i, EVENT_PATH, i);
+ /* try to open the device */
+ eventfd = open (filename, O_RDONLY);
+ /* if opening suceeded */
+ if (eventfd = 0)
+ {
+ /* check the id of the event interface */
+ ioctl (eventfd, EVIOCGID, id);
+ if (want_verbose)
+ {
+ ioctl (eventfd, EVIOCGNAME(sizeof(name)), name);
+ printf(%s: input: %s name: %s bustype: %d vendor: %d product: %d
version: %d\n,
+ PACKAGE, filename, name, id.bustype, id.vendor, id.product,
id.version);
+ }
+
+ if ((id.product 0xfff) == 0x01f (id.vendor 0xfff) == 0x01f)
+ {
+ if (!want_quiet)
+ printf (%s: Virtual event device found at %s\n, PACKAGE,
filename);
+ event_device = filename;
+ break;
+ }
+ else
+ {
+ close (eventfd);
+ eventfd = -1;
+ }
+ }
+}
+
+ /* when no event filedesctiptor is set e.g. the event device could not be
found */
+ if (!(eventfd = 0))
+{
+ free (filename);
+
+ /* check if we are root */
+ if (geteuid () != 0)
+ {
+ printf
+ (%s: Couldn't access /dev/input/event* perhaps you are not
root?\n,
+PACKAGE);
+ exit (0);
+ }
+
+ /* check if the kernel module is loaded */
+ if (!system (lsmod | grep evdev))
+ {
+ printf
+ (%s: The evdev kernel module is already loaded, so it seems\n,
+PACKAGE);
+ printf (%s: something else is going wrong.\n, PACKAGE);
+ exit (0);
+ }
+
+ /* when the kernel module is not loaded and we are not root
+ * try to load the kernel module... */
+ printf (%s: I' will try to load some modules...\n, PACKAGE);
+ printf (%s: loading evdev...\n, PACKAGE);
+ if (!system (modprobe evdev))
+ {
+ printf (%s: loading succeeded.\n, PACKAGE);
+ return find_button_device ();
+ }
+ else
+ printf (%s: Something wrent wong loading the evdev module.\n,
+ PACKAGE);
+
+ exit (0);
+}
+
+ return eventfd;
+} /* »»» */
+
/* static void eject_cdrom () ««« */
static void
eject_cdrom ()
Re: mouseemu 0.15 not working at all?
input: mouseemu virtual keyboard as /class/input/input6 input: mouseemu virtual mouse as /class/input/input7 /sys/class/input/input6 and input7 exist. any hints? Try cat /dev/input/event6 or cat /dev/input/event7 and see if typing or moving the mouse/trackpad shows any activity. If yes, recompiling mouseemu using a recent version of the kernel headers might help (use Mich Lanners' mouseemu binary to try this out). Do you have other processes that use the event devices? Does any of these grab the events for exclusive use? (See ls -lR of /sys/class/input for a list of devices, and run find /proc -name event\* to see who uses them) If no output shows on any of the above commands, that's rather likely. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu 0.15 not working at all?
hy michael, input: mouseemu virtual keyboard as /class/input/input6 input: mouseemu virtual mouse as /class/input/input7 /sys/class/input/input6 and input7 exist. any hints? Try cat /dev/input/event6 or cat /dev/input/event7 and see if typing or moving the mouse/trackpad shows any activity. no, none at all. If yes, recompiling mouseemu using a recent version of the kernel headers might help (use Mich Lanners' mouseemu binary to try this out). Do you have other processes that use the event devices? none that i am aware of. i have read that pbbuttonsd might be a problem therefor i have uninstalled that (apt-get --purge remove pbbuttonsd). but no success either. Does any of these grab the events for exclusive use? (See ls -lR of /sys/class/input for a list of devices, and run find /proc -name event\* to see who uses them) If no output shows on any of the above commands, that's rather likely. no output indeed. so do i understand you correctly? because of that, some other application steals the events which therefor cannot be processed by mouseemu? any ideas which applications that might be? -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu conflicts with ikeyd
Hello, On 18 Feb, this message from Kirill Kuvaldin echoed through cyberspace: Recently I've installed ikeyd and mouseemu debian packages. It seems they conflict between themselves, so mouseemu overrides ikeyd settings, i.e. ikeyd is absolutely blocked, pressing F12 doesn't lead to cdrom ejecting, and F4/F5 doesn't adjust the volume. I don't think it's mouseemu overriding settings of ikeyd, but more a plane incompatibilitz of the two. I ave a similar issue with mouseemu and pbbuttonsd. Can you try whether this locally compiled mouseemu fixes your problem: http://www.cpu.lu/~mlan/ftp/debian/mouseemu_0.15-2-ln1_powerpc.deb What kernel version are you running? If this fixes your problem, we have enough info to file a bug against mouseemu. Cheers Michel - Michel Lanners | Read Philosophy. Study Art. 23, Rue Paul Henkes|Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED]| http://www.cpu.lu/~mlan| Learn Always. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu conflicts with ikeyd
Mich Lanners [EMAIL PROTECTED] writes: Hello, On 18 Feb, this message from Kirill Kuvaldin echoed through cyberspace: Recently I've installed ikeyd and mouseemu debian packages. It seems they conflict between themselves, so mouseemu overrides ikeyd settings, i.e. ikeyd is absolutely blocked, pressing F12 doesn't lead to cdrom ejecting, and F4/F5 doesn't adjust the volume. I don't think it's mouseemu overriding settings of ikeyd, but more a plane incompatibilitz of the two. I ave a similar issue with mouseemu and pbbuttonsd. Can you try whether this locally compiled mouseemu fixes your problem: http://www.cpu.lu/~mlan/ftp/debian/mouseemu_0.15-2-ln1_powerpc.deb What kernel version are you running? If this fixes your problem, we have enough info to file a bug against mouseemu. I've installed your mouseemu package but unfortunately it didn't solve my problem. Neither ikeyd nor pbbuttonsd can't still work properly with mouseemu running. My kernel is 2.6.8-powerpc (default in sarge). Any ideas why mouseemu behaves in such a way? -- kuvkir -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu fails on ppc64 ?
Have you tried building mouseemu as a 64 bits binary ? How would I do that? I have tried rebuilding mouseemu with a vanilla apt-build and manually with make. apt-build failed claiming not to find 'ld' (binutils is installed, ld is there, etc) and the manually built binary recreates the same error (ioctl UI_SET_KEYBIT: Invalid argument). Are there any flags or options to pass in order to build it 64bit? Hints or pointers to RTFM would be appreicated! Thanks, Michal --- Here is an extract of the output of apt-build: /usr/bin/make make[1]: Entering directory `/var/cache/apt-build/build/mouseemu-0.15' gcc -Wall -g -o mouseemu mouseemu.c collect2: cannot find 'ld' make[1]: *** [all] Error 1 make[1]: Leaving directory `/var/cache/apt-build/build/mouseemu-0.15' make: *** [build-stamp] Error 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu fails on ppc64 ?
On Fri, 2005-11-25 at 17:52 +0100, Michal wrote: Have you tried building mouseemu as a 64 bits binary ? How would I do that? I have tried rebuilding mouseemu with a vanilla apt-build and manually with make. apt-build failed claiming not to find 'ld' (binutils is installed, ld is there, etc) and the manually built binary recreates the same error (ioctl UI_SET_KEYBIT: Invalid argument). Are there any flags or options to pass in order to build it 64bit? Hints or pointers to RTFM would be appreicated! -m64 Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu fails on ppc64 ?
-m64 ok, that failed, with the output below. For the record, here are the steps I took: 1. first it complained with this: e2011# gcc -Wall -m64 -g -o mouseemu mouseemu.c /usr/bin/ld: skipping incompatible /usr/lib/gcc/powerpc-linux-gnu/4.0.3/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: skipping incompatible /usr/lib/gcc/powerpc-linux-gnu/4.0.3/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status 2. to cure this I installed lib64gcc1 (it turned out that eg /usr/lib/gcc/powerpc-linux-gnu/4.0.3/libgcc_s_64.so was pointing to an inexistant /lib64/libgcc_s.so.1, provided by lib64gcc1). And to make it visible to gcc, I added this symlink: /usr/lib64/libc.so - /lib64/libc.so.6 3. Then compiling mouseemu fails with: # gcc -Wall -m64 -L/usr/lib64/ -g -o mouseemu mouseemu.c /usr/bin/ld: warning: powerpc:common architecture of input file `/usr/lib/gcc/powerpc-linux-gnu/4.0.3/../../../crt1.o' is incompatible with powerpc:common64 output /usr/bin/ld: warning: powerpc:common architecture of input file `/usr/lib/gcc/powerpc-linux-gnu/4.0.3/../../../crti.o' is incompatible with powerpc:common64 output /usr/bin/ld: warning: powerpc:common architecture of input file `/usr/lib/gcc/powerpc-linux-gnu/4.0.3/../../../crtn.o' is incompatible with powerpc:common64 output /usr/bin/ld: can not size stub section: Bad value /usr/lib/gcc/powerpc-linux-gnu/4.0.3/../../../crt1.o: In function `_start':../sysdeps/powerpc/powerpc32/elf/start.S:86: relocation truncated to fit: R_PPC_REL24 against `__libc_start_main' /usr/lib/gcc/powerpc-linux-gnu/4.0.3/../../../crti.o: In function `call_gmon_start':/build/buildd/glibc-2.3.5/build-tree/powerpc-libc/csu/crti.S:16: undefined reference to `_GLOBAL_OFFSET_TABLE_' /usr/bin/ld: /tmp/ccS6z7RF.o(.text+0x68): unresolvable R_PPC64_REL24 relocation against symbol `gettimeofday@@GLIBC_2.3' /tmp/ccS6z7RF.o: In function `send_event':/var/cache/apt-build/build/mouseemu-0.15/mouseemu.c:67: relocation truncated to fit: R_PPC64_REL24 against symbol `gettimeofday@@GLIBC_2.3' defined in .opd section in /usr/lib64//libc.so /usr/bin/ld: /tmp/ccS6z7RF.o(.text+0x84): unresolvable R_PPC64_REL24 relocation against symbol `write@@GLIBC_2.3' :/var/cache/apt-build/build/mouseemu-0.15/mouseemu.c:68: relocation truncated to fit: R_PPC64_REL24 against symbol `write@@GLIBC_2.3' defined in .opd section in /usr/lib64//libc.so [... and many more such ...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu fails on ppc64 ?
On Fri, 2005-11-25 at 23:47 +0100, Michal wrote: -m64 ok, that failed, with the output below. For the record, here are the steps I took: 1. first it complained with this: e2011# gcc -Wall -m64 -g -o mouseemu mouseemu.c /usr/bin/ld: skipping incompatible /usr/lib/gcc/powerpc-linux-gnu/4.0.3/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: skipping incompatible /usr/lib/gcc/powerpc-linux-gnu/4.0.3/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status 2. to cure this I installed lib64gcc1 (it turned out that eg /usr/lib/gcc/powerpc-linux-gnu/4.0.3/libgcc_s_64.so was pointing to an inexistant /lib64/libgcc_s.so.1, provided by lib64gcc1). And to make it visible to gcc, I added this symlink: /usr/lib64/libc.so - /lib64/libc.so.6 3. Then compiling mouseemu fails with: Dunno, something must be busted with debian's biarch toolchain when building 64 bits ... Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu fails on ppc64 ?
I could probably fix it with time but I don't have that time at hand now. I've asked the maintainer but I'm not too hopeful. Thanks for looking into it! Does anyone know of a way to get mouse button emulation on ppc64 other than sysctl (which doesn't work anymore) and mouseemu (which doesn't work yet)? Thanks, Michal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu fails on ppc64 ?
On Thu, 2005-11-24 at 16:15 +0100, [EMAIL PROTECTED] wrote: I could probably fix it with time but I don't have that time at hand now. I've asked the maintainer but I'm not too hopeful. Thanks for looking into it! Does anyone know of a way to get mouse button emulation on ppc64 other than sysctl (which doesn't work anymore) and mouseemu (which doesn't work yet)? Have you tried building mouseemu as a 64 bits binary ? Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu fails on 2.6.14 ?
Does anyone else have problems when trying to use mouseemu on 2.6.14?
(I have googled this and browsed the bug reports, but found nothing).
On a PowerMac 7,2 running unstable, I get:
$ /etc/init.d/mouseemu restart
ioctl32(mouseemu:2395): Unknown cmd fd(5) cmd(80045564){00} arg(0001)
on /dev/input/uinput
ioctl UI_SET_KEYBIT: Invalid argument
That's a new one then. What precise kernel version, and where did the
source come from?
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu fails on 2.6.14 ?
hi -
$ /etc/init.d/mouseemu restart
ioctl32(mouseemu:2395): Unknown cmd fd(5) cmd(80045564){00} arg(0001)
on /dev/input/uinput
ioctl UI_SET_KEYBIT: Invalid argument
That's a new one then. What precise kernel version, and where did the
source come from?
The kernel is the one found in unstable as of today, ie
linux-image-2.6.14-2-powerpc64:
$ uname -a
Linux e2011 2.6.14-2-powerpc64 #1 SMP Wed Nov 16 02:17:10 UTC 2005 ppc64
GNU/Linux
thanks,
Michal
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu fails on 2.6.14 ?
On Wed, Nov 23, 2005 at 10:17:09PM +0100, Michal wrote:
hi -
$ /etc/init.d/mouseemu restart
ioctl32(mouseemu:2395): Unknown cmd fd(5) cmd(80045564){00}
arg(0001) on /dev/input/uinput
ioctl UI_SET_KEYBIT: Invalid argument
That's a new one then. What precise kernel version, and where did the
source come from?
The kernel is the one found in unstable as of today, ie
linux-image-2.6.14-2-powerpc64:
$ uname -a
Linux e2011 2.6.14-2-powerpc64 #1 SMP Wed Nov 16 02:17:10 UTC 2005 ppc64
GNU/Linux
I just tested on my new powerbook. Mouseemu starts just fine. I thus
suspect this is a problem specific to powerpc64. I'm not sure if you
have to recompile it for powerpc64, because it directly calls ioctl on
the uinput device. Probably someone with a deeper understanding of the
specifics of running 32bit userland programs on a 64bit kernel can shed
some light on this.
Gaudenz
--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu fails on 2.6.14 ?
Linux e2011 2.6.14-2-powerpc64 #1 SMP Wed Nov 16 02:17:10 UTC 2005 ppc64 GNU/Linux I just tested on my new powerbook. Mouseemu starts just fine. I thus suspect this is a problem specific to powerpc64. I'm not sure if you have to recompile it for powerpc64, because it directly calls ioctl on the uinput device. Probably someone with a deeper understanding of the specifics of running 32bit userland programs on a 64bit kernel can shed some light on this. The ioctl need a translation function for 32 bits on 64 bits... Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu fails on 2.6.14 ?
I just tested on my new powerbook. Mouseemu starts just fine. I thus suspect this is a problem specific to powerpc64. I'm not sure if you have to recompile it for powerpc64, because it directly calls ioctl on the uinput device. Probably someone with a deeper understanding of the specifics of running 32bit userland programs on a 64bit kernel can shed some light on this. Ok, I've looked more and the answer is: don't use uinput on 64 bits machines with 32 bits userland. It's been designed (like the rest of the input layer) in the worst possible way to implement compatibility with 32 and 64 bits. I could probably fix it with time but I don't have that time at hand now. I've asked the maintainer but I'm not too hopeful. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu in need of a new maintainer
My iBook G4 died an horrible death - it's been showered by a leak in the roof, basically - and won't start after drying. As I won't be able to buy another one, I probably won't be able to hack on mouseemu either for a while. If anyone wants to take maintainership, he's welcome to do so. You're not talking about Debian package maintainership, right? That package is maintained by Gaudenz Steinlin according to the BTS. Speaking of bugs, it seems #304734 should be closed - the consensus was the interaction between pbbuttonsd and mouseemu were caused by insufficient number of event devices available, or pbbuttonsd (old versions) using a hardcoded number of event devices that was too low. What's to be done on mouseemu right now, beyond bugfixes? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu replacement in pbbuttonsd
On Tue, 1 Mar 2005 09:58:54 + (UTC) Joerg Sommer [EMAIL PROTECTED] wrote: Hi, following feature has been added to pbbuttonsd: The trackpad will be reconfigured to 'notap' while typing. The old trackpad mode is restored after roundabout 0.6 seconds. This seems a good value to me also for people using the two finger typing method (like me :-)) and who is not so fast in typing. This feature is only availabe from CVS (on sourceforge.net) for test and it is not configurable yet. This may change before next release and depends on users feedback. Pbbuttonsd can't replace mouseemu. Although mouseemu uses some of pbbuttonsd original code and routines, its excellent features can't be integrated easily. Anyway, some people think pbbuttonsd is 'fat' enough and needs no more features. ;-) The latest feature extension simply reconfigures the trackpad hardware to its 'move only' or 'notap' mode. This is pretty simple but works also with kernel 2.4. Please test the feature and have an eye on possible conflicts with mouseemu. Thanks and best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu replacement in pbbuttonsd
On Sun, Mar 06, 2005 at 12:28:37PM +0100, Matthias Grimm wrote: On Tue, 1 Mar 2005 09:58:54 + (UTC) Joerg Sommer [EMAIL PROTECTED] wrote: Hi, following feature has been added to pbbuttonsd: The trackpad will be reconfigured to 'notap' while typing. The old trackpad mode is restored after roundabout 0.6 seconds. This seems a good value to me also for people using the two finger typing method (like me :-)) and who is not so fast in typing. This feature is only availabe from CVS (on sourceforge.net) for test and it is not configurable yet. This may change before next release and depends on users feedback. Any patch? [...] Regards, wrobell [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu replacement in pbbuttonsd
On 06 Mar 2005 at 12h03, Matthias Grimm wrote: Hi, Please test the feature and have an eye on possible conflicts with mouseemu. Mouseemu just drops any mouse event during X milliseconds after a keypress (excluding control keys like shift, command or control), so this shouldn't inferfere. -- Colin http://ayttm.sf.net/ : Chat with your friends via msn, aim, yahoo, and more -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu replacement in pbbuttonsd
On Sun, 6 Mar 2005 13:50:08 +0100 wrobell [EMAIL PROTECTED] wrote: This feature is only availabe from CVS (on sourceforge.net) for test and it is not configurable yet. This may change before next release and depends on users feedback. Any patch? attached, it is based on 0.6.7a. Best Regards Matthias notap.patch.gz Description: Binary data
Re: mouseemu replacement in pbbuttonsd
On Tuesday 01 March 2005 11:08, Vincent Bernat wrote: hotplug is a better place to disable/enable the touchpad when you plug an external mouse. Ahh, thanks :) -- Lee. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu replacement in pbbuttonsd
On Tue, Mar 01, 2005 at 12:08:37PM +0100, Vincent Bernat wrote: hotplug is a better place to disable/enable the touchpad when you plug an external mouse. How would you go about doing that? Does anybody have any examples they can provide? -- gram -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu replacement in pbbuttonsd
On Tuesday 01 March 2005 19:23, Graham Wilson wrote: On Tue, Mar 01, 2005 at 12:08:37PM +0100, Vincent Bernat wrote: hotplug is a better place to disable/enable the touchpad when you plug an external mouse. How would you go about doing that? Does anybody have any examples they can provide? I googled it, and got this: http://www.wlug.org.nz/HotPlugNotes Look towards the bottom of the page :) -- Lee. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu replacement in pbbuttonsd
On Mon, 28 Feb 2005 13:52:44 + (UTC) Joerg Sommer [EMAIL PROTECTED] wrote: Hi, my problem with the touchpad is, while typing hitting on the touchpad and this generates a click and my cursor jumps away. I know mouseemu exists. But pbbuttonsd already watches for key events. Isn't it possible to make it switch the mode of the touchpad, while typing? Yes it would be. Is this a feature request? :-) Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu replacement in pbbuttonsd
On Mon, Feb 28, 2005 at 10:47:28PM +0100, Matthias Grimm wrote: On Mon, 28 Feb 2005 13:52:44 + (UTC) Yes it would be. Is this a feature request? :-) yes -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 When you dance with the devil, you wait for the song to stop. --Barry the Baptist (Lock, Stock and Two Smoking Barrels) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu (was: Re: initial XF86Config)
On Thu, Jul 29, 2004 at 12:14:30PM -0400, Rick Thomas wrote: I assume I download mouseemu_0.12-1_powerpc.deb -- But what do I do once I've done that? dpkg -i mouse*deb -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.26|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 So, Lord Helmet, at last we meet again for the first time for the last time. --Lone Starr (Spaceballs)
Re: mouseemu (was: Re: initial XF86Config)
On Thu, Jul 29, 2004 at 10:16:10AM +0200, Sebastian Henschel wrote: hi.. * Rick Thomas [EMAIL PROTECTED] [2004-07-29 09:20 +0200]: Mouse button emulation! There's a thought... Yellowdog can do it (in fact does it by default). What do I have to do to get it on Debian PowerPC (OldWorld)? 8-/ dunno, if it works for oldworld macs, but http://www.geekounet.org/powerbook/files/mouseemu.tar.gz There are debian packages at: http://honk.physik.uni-konstanz.de/~agx/linux-ppc/debian/mouseemu/ -- Guido signature.asc Description: Digital signature
Re: mouseemu (was: Re: initial XF86Config)
hello guido.. * Guido Guenther [EMAIL PROTECTED] [2004-07-29 12:14 +0200]: On Thu, Jul 29, 2004 at 10:16:10AM +0200, Sebastian Henschel wrote: hi.. * Rick Thomas [EMAIL PROTECTED] [2004-07-29 09:20 +0200]: Mouse button emulation! There's a thought... Yellowdog can do it (in fact does it by default). What do I have to do to get it on Debian PowerPC (OldWorld)? 8-/ dunno, if it works for oldworld macs, but http://www.geekounet.org/powerbook/files/mouseemu.tar.gz There are debian packages at: http://honk.physik.uni-konstanz.de/~agx/linux-ppc/debian/mouseemu/ fine. did you think about an ITP for this? will you make it apt-gettable like mplayer (and perhaps merge the repositories)? bye, sebastian -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
Re: mouseemu (was: Re: initial XF86Config)
On Thu, Jul 29, 2004 at 12:57:18PM +0200, Sebastian Henschel wrote: http://www.geekounet.org/powerbook/files/mouseemu.tar.gz There are debian packages at: http://honk.physik.uni-konstanz.de/~agx/linux-ppc/debian/mouseemu/ fine. did you think about an ITP for this? will you make it apt-gettable like mplayer (and perhaps merge the repositories)? Nope. In contrast to mplayer this package can go into the Debian repository without any problems but since I don't want to maintain it, someone else will have to pick this task... -- Guido signature.asc Description: Digital signature
Re: mouseemu (was: Re: initial XF86Config)
On Thursday, July 29, 2004, at 05:31 AM, Guido Guenther wrote: On Thu, Jul 29, 2004 at 10:16:10AM +0200, Sebastian Henschel wrote: hi.. * Rick Thomas [EMAIL PROTECTED] [2004-07-29 09:20 +0200]: Mouse button emulation! There's a thought... Yellowdog can do it (in fact does it by default). What do I have to do to get it on Debian PowerPC (OldWorld)? 8-/ dunno, if it works for oldworld macs, but http://www.geekounet.org/powerbook/files/mouseemu.tar.gz There are debian packages at: http://honk.physik.uni-konstanz.de/~agx/linux-ppc/debian/mouseemu/ -- Guido Guido, Many thanks! That looks promising. We'll see if it works with my ADB mouse. I'll report back here after I've tried it. Forgive me for being a bit newbie about things Debian, but... How do I install this? I assume I download mouseemu_0.12-1_powerpc.deb -- But what do I do once I've done that? Thanks! Rick
Re: mouseemu not working
On 09 Jun 2004 at 14h06, [EMAIL PROTECTED] wrote: Hi, i did a 2.6.4 kernel (-ck2) for my iBook. However, mouseemu refuses to start because it can't access any of the required /dev/uinput How can i create it / fix the situation? Does /dev/misc/uinput or /dev/input/uinput exist ? If yes then just make a symlink... If not, look into udev or devfs configuration... I can't really help you much more, I had no problem with uinput setup :-s HTH, -- Colin
