Dear list, Last night I found a bit of a odd issue with a touchpad on a laptop running Linux. I tried to open the mouse as a HID device and it correctly found the one mouse attached, being the build in touchpad which it described as acting through ps2 (I believe that's normal for touchpads). The odd thing is that ChucK didn't get any data from it when moving my finger over it or clicking the buttons. I then pluged in a Logitech optical mouse which was -after a restart of the vm for safety- identified as mouse 0 and which did operate correctly. I'd be happy to run any and all tests that might help diagnose the bug if it's deemed one. I should note that this was running a non-standard version of the Mini, being one with the latest ChucK plugged in and Tom's CNoise fix on top of that but I don't think either should affect this. Yours, Kas.
On 17 Jul 2009, at 07:03, Kassen wrote:
Last night I found a bit of a odd issue with a touchpad on a laptop running Linux. I tried to open the mouse as a HID device and it correctly found the one mouse attached, being the build in touchpad which it described as acting through ps2 (I believe that's normal for touchpads). The odd thing is that ChucK didn't get any data from it when moving my finger over it or clicking the buttons.
I then pluged in a Logitech optical mouse which was -after a restart of the vm for safety- identified as mouse 0 and which did operate correctly.
You might want to have a look at the spacenavigator thread, for example https://lists.cs.princeton.edu/pipermail/chuck-users/2009-May/004258.html and what follows. The HIDs work so that they have a series of button which can give range of values and they are also marked for intended use. So a mouse report relative position or velocities (don't remember which), whereas a trackpad report absolute position - a different variable. I hacked up a program that reports them all on Mac OS X. Chuck only implements a few of them. On Mac OS X, all HISs in each category start at 0. So there is no need going up in numbers. Hans
Hans; You might want to have a look at the spacenavigator thread, for example
https://lists.cs.princeton.edu/pipermail/chuck-users/2009-May/004258.html and what follows.
That is a very different issue, in that case we were dealing with a device of a type unknown to ChucK. Here we are dealing with a laptop touchpad and touchpads work as mice (in addition to the other capabilities that you outline below which we don't yet deal with). Up to here ChucK agrees with me, this is what it prints when running mouse.ck; [chuck](VM): sporking incoming shred: 1 (mouse.ck)... mouse 'SynPS/2 Synaptics TouchPad' ready
The HIDs work so that they have a series of button which can give range of values and they are also marked for intended use. So a mouse report relative position or velocities (don't remember which), whereas a trackpad report absolute position - a different variable.
I do believe touchpads also output the change in position. I think it might be interesting to also read this absolute position for ChaosPad style modulations but that's something for the wishlist. Touchpads should work -I feel- and generally they do; Plork/Slork did play "bowed touchpad" by swiping them and sending the resultant signal to some sort of soundsource in ChucK.
I hacked up a program that reports them all on Mac OS X.
Chuck only implements a few of them.
That is true. I think part of the reason for that is that they aren't very standardised. Some touchpads also report on the pressure excerted and others do things like multi-touch. I would imagine that a Synaptic touchpad on a off-the-shelf laptop should be fairly standard, at least at it's core.
On Mac OS X, all HISs in each category start at 0. So there is no need going up in numbers.
I'm not sure what you mean by that; the first one is indeed always called "0" but that may not be the one we are interested in or we may be using several devices at the same time; I regularly perform with 3 joystick devices, for example. Yours, Kas.
On 17 Jul 2009, at 15:58, Kassen wrote:
You might want to have a look at the spacenavigator thread, for example https://lists.cs.princeton.edu/pipermail/chuck-users/2009-May/004258.html and what follows.
That is a very different issue, in that case we were dealing with a device of a type unknown to ChucK. Here we are dealing with a laptop touchpad and touchpads work as mice (in addition to the other capabilities that you outline below which we don't yet deal with).
The general interface just provides a list of (device_type, button_number, button_range, button_intended_use) or something (don't remember details). Chuck implements some of those choices, hardcoded with respect to (device_type, button_intended_use).
Up to here ChucK agrees with me, this is what it prints when running mouse.ck;
[chuck](VM): sporking incoming shred: 1 (mouse.ck)... mouse 'SynPS/2 Synaptics TouchPad' ready
So this means that the touchpad has been registered as type mouse.
The HIDs work so that they have a series of button which can give range of values and they are also marked for intended use. So a mouse report relative position or velocities (don't remember which), whereas a trackpad report absolute position - a different variable.
I do believe touchpads also output the change in position.
They may or may not, I think - they HIDs can pretty much choose what varibles they want to provide. There was another thread withy this track-pad problem. If you have a Mac with gcc on it, you might try the program I hacked up. It lists all the variables for all attached HIDs.
I think it might be interesting to also read this absolute position for ChaosPad style modulations but that's something for the wishlist.
From what I could see, is a dynamic interface, like in that program. Then any HID device with any of its variables can be used.
On Mac OS X, all HISs in each category start at 0. So there is no need going up in numbers.
I'm not sure what you mean by that; the first one is indeed always called "0" but that may not be the one we are interested in or we may be using several devices at the same time; I regularly perform with 3 joystick devices, for example.
The API provides, for each HID device type, an iterator, that iterators through all devices. Somehow it is the standard to start at 0. So unless one attahces and removes devices, there will be no gaps in numbers. Hans
Hey Kassen, One thing to try is to see if you can read any data from the underlying input file for that device. To get the file path, try running a basic ChucK program that opens that mouse (e.g. hid/mouse.ck from the examples directory) and then use lsof: chuck examples/hid/mouse.ck >& /dev/null & lsof -c chuck | grep event lsof will list all files of the form /dev/input/event# at least once; the one that is listed twice is the one you want. Take that file path (for me its /dev/input/event5) and pass it to od: od < /dev/input/event5 and then move your mouse around. If you see a bunch of binary data in octal format printed to the screen roughly at the same time as when you move the mouse around, then it seems likely chuck is mishandling or misinterpreting the input from this device. If you don't see that or anything else printed to the screen when running this command, then probably at some lower level this device is identifying itself but does not actually provide data through the standard channels. If its the former then let me know and we can try to figure out in greater depth what data this device is reporting that chuck seems to have such a problem with; in the latter case there is probably not much that chuck can do. On another note, I recall that I owe you a response to your chuck-dev post a few weeks ago; thats forthcoming :) spencer On Jul 17, 2009, at 6:58 AM, Kassen wrote:
Hans;
You might want to have a look at the spacenavigator thread, for example https://lists.cs.princeton.edu/pipermail/chuck-users/2009-May/004258.html and what follows.
That is a very different issue, in that case we were dealing with a device of a type unknown to ChucK. Here we are dealing with a laptop touchpad and touchpads work as mice (in addition to the other capabilities that you outline below which we don't yet deal with). Up to here ChucK agrees with me, this is what it prints when running mouse.ck;
[chuck](VM): sporking incoming shred: 1 (mouse.ck)... mouse 'SynPS/2 Synaptics TouchPad' ready
The HIDs work so that they have a series of button which can give range of values and they are also marked for intended use. So a mouse report relative position or velocities (don't remember which), whereas a trackpad report absolute position - a different variable.
I do believe touchpads also output the change in position. I think it might be interesting to also read this absolute position for ChaosPad style modulations but that's something for the wishlist. Touchpads should work -I feel- and generally they do; Plork/Slork did play "bowed touchpad" by swiping them and sending the resultant signal to some sort of soundsource in ChucK.
I hacked up a program that reports them all on Mac OS X.
Chuck only implements a few of them.
That is true. I think part of the reason for that is that they aren't very standardised. Some touchpads also report on the pressure excerted and others do things like multi-touch. I would imagine that a Synaptic touchpad on a off-the-shelf laptop should be fairly standard, at least at it's core.
On Mac OS X, all HISs in each category start at 0. So there is no need going up in numbers.
I'm not sure what you mean by that; the first one is indeed always called "0" but that may not be the one we are interested in or we may be using several devices at the same time; I regularly perform with 3 joystick devices, for example.
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On 17 Jul 2009, at 07:03, Kassen wrote:
Last night I found a bit of a odd issue with a touchpad on a laptop running Linux. I tried to open the mouse as a HID device and it correctly found the one mouse attached, being the build in touchpad which it described as acting through ps2 (I believe that's normal for touchpads). The odd thing is that ChucK didn't get any data from it when moving my finger over it or clicking the buttons.
Sorry, I was thinking about a graphics tablet. I'm looking on http://en.wikipedia.org/wiki/USB_human_interface_device_class The HID protocols are evidently only for USB connections. So if your trackpad is acting through PS/2 http://en.wikipedia.org/wiki/IBM_Personal_System/2#Keyboard.2Fmouse_interfac... that is a different API. Don't know how that works - the last one I saw was on a Mac made in the mid-1990s. Hans
Hans; Sorry, I was thinking about a graphics tablet. I suspected a misunderstanding like that. I'm well aware that graphics tablets are currently unsupported. I was avoiding the word "scratchpad" as on this evening I was experimenting with a mouse-based DIY turtable so I imagined that might result in confusion later on and the word "trackpad" eluded me. Sorry, my fault.
I'm looking on http://en.wikipedia.org/wiki/USB_human_interface_device_class The HID protocols are evidently only for USB connections.
Well, yes, strictly speaking. However I have been using PS/2 keyboards with ChucK for quite a while (because my favourite keyboards pre-date the USB standard) and have never had a issue with those under ChucK. I'd also like to point out that if this device were completely unlike a HID device the ChucK HID abstraction should be unable to open it. Instead it dutifully reports it's a PS/2 device. My issue is that it does get opened as a mouse but that it doesn't give any data. If ChucK would say "Hey, I see no USB mouse so you can't have a HID abstraction of any mouse at all." it'd have to admit that that would be inconvenient yet fair. I'm not familiar with the Mac situation, having never owned one, but this is a bog-standard setup for non-Mac laptops. I believe it even makes sense as supposedly PS/2 has some advantages over USB for mice in how it uses system bus bandwith. We'd need to consult a hardware expert to verify that; I certainly don't know that much about motherboard architecture or OS design. This might also be limited by factors like maximum poll-rate and resolution; I'm not sure but I don't think trackpad makers are very concerned with those factors; these are hardly expensive high-performance interface devices. Interestingly; according to ChucK there is a second mouse device here that can be opened which looks like a emulation layer for macintosh mice. I have no idea what that's doing there and why but it's not giving me any useful signals either. I could look up the exact name if that would be relevant but I would suspect it's simply there in case Ubuntu would be installed on a Macbook. Maybe Apple instead uses a internal USB bus or something else altogether. Yours, Kas.
On 17 Jul 2009, at 23:49, Kassen wrote:
I'm looking on http://en.wikipedia.org/wiki/USB_human_interface_device_class The HID protocols are evidently only for USB connections.
Well, yes, strictly speaking. However I have been using PS/2 keyboards with ChucK for quite a while (because my favourite keyboards pre-date the USB standard) and have never had a issue with those under ChucK. I'd also like to point out that if this device were completely unlike a HID device the ChucK HID abstraction should be unable to open it. Instead it dutifully reports it's a PS/2 device. My issue is that it does get opened as a mouse but that it doesn't give any data. If ChucK would say "Hey, I see no USB mouse so you can't have a HID abstraction of any mouse at all." it'd have to admit that that would be inconvenient yet fair.
I checked in a program the HID variables for the mouse and trackpad are the same X-Axis Y-Axis. But 'chuck' probably just calls some interface that is available on the OS. That is how it works on Mac OS X. So if the OS admits PS/2 devices, then should feed some information into that interface, which is what 'chuck' then reports.
I'm not familiar with the Mac situation, having never owned one, but this is a bog-standard setup for non-Mac laptops. I believe it even makes sense as supposedly PS/2 has some advantages over USB for mice in how it uses system bus bandwith. We'd need to consult a hardware expert to verify that; I certainly don't know that much about motherboard architecture or OS design.
Though some older protocols like SCSI have advantages over more modern, consumer friendly ones like USB, I don't there are any system bus issues for these, as one has some intermediate hardware that provides the communication. In the 1970s I assembled a computer, that wrote the keyboard characters directly into memory, which the CPU checked in a loop. This is highly inefficient way to handle it.
This might also be limited by factors like maximum poll-rate and resolution;
For the USB keyboards I have checked, this seems to be limitation of the keyboard, that is, even before the data is sent to the computer. This is because it differs with the keyboard. The computer is so fast that it easily can handle any human typed key roll-over. The slow USB 1 bus is on about 12 Mb/s, which should admit for tens of thousands of key stroke in a tenth of a second. When experimenting with the diatonic key map, the problem is mostly due to other process running. One notorious one is looking for RSS feeds.
I'm not sure but I don't think trackpad makers are very concerned with those factors; these are hardly expensive high-performance interface devices.
Interestingly; according to ChucK there is a second mouse device here that can be opened which looks like a emulation layer for macintosh mice. I have no idea what that's doing there and why but it's not giving me any useful signals either. I could look up the exact name if that would be relevant but I would suspect it's simply there in case Ubuntu would be installed on a Macbook. Maybe Apple instead uses a internal USB bus or something else altogether.
I think I tried a Mac keyboard once on a Windows, finding it not working. One needs to have a driver installed. Each device may require its own. The USB HID interface unifies those, so that only one driver is needed, which then can be supplied by the OS. The latest version of this USB HID interface or standard was issued this year. So perhaps it was not available when 'chuck' was written. Hans
Hans; I checked in a program the HID variables for the mouse and trackpad are the
same X-Axis Y-Axis. But 'chuck' probably just calls some interface that is available on the OS. That is how it works on Mac OS X. So if the OS admits PS/2 devices, then should feed some information into that interface, which is what 'chuck' then reports.
Yes, that's basically what I imagined was going on as well.
Though some older protocols like SCSI have advantages over more modern, consumer friendly ones like USB, I don't there are any system bus issues for these, as one has some intermediate hardware that provides the communication. In the 1970s I assembled a computer, that wrote the keyboard characters directly into memory, which the CPU checked in a loop. This is highly inefficient way to handle it.
Ah, yes, I would indeed imagine that would be fast. For all I know that's what Apple is doing now... Having full control over the hardware specs would allow you to do that. The only downside that I can see would be that spilling drinks in the keyboard might cause the memory itself to be fried but I suppose you might be able to have some sort of protection against that.
This might also be limited by factors like maximum poll-rate and
resolution;
For the USB keyboards I have checked, this seems to be limitation of the keyboard, that is, even before the data is sent to the computer. This is because it differs with the keyboard. The computer is so fast that it easily can handle any human typed key roll-over. The slow USB 1 bus is on about 12 Mb/s, which should admit for tens of thousands of key stroke in a tenth of a second.
I meant PS/2 might be limited there. In recent years the quality of high performance mice has gone up quite a bit, probably originally inspired by games like Quake. It was chiefly mouse signals that I was refering to. Sadly (I feel) the quality of keyboards hasn't made the same progression and keyboard ghosting is now typically worse then it was on keyboards from the 80's.
When experimenting with the diatonic key map, the problem is mostly due to other process running. One notorious one is looking for RSS feeds.
Yes, I was a bit disappointed when I found out about that as well though I do think that's a quite different issue. I think I tried a Mac keyboard once on a Windows, finding it not working.
One needs to have a driver installed. Each device may require its own. The USB HID interface unifies those, so that only one driver is needed, which then can be supplied by the OS. The latest version of this USB HID interface or standard was issued this year. So perhaps it was not available when 'chuck' was written.
Odd. I've never seen a keyboard not work, I think. Special keys (like volume or "sleep" ones) may need a driver in my experience but the keyboard itself always worked. I think you can even take a ps/2 keyboard, use a USB adapter and plug it straight into a Mac, provided you are willing to remap some stuff to the "Apple" and related keys. Yours, Kas.
On 18 Jul 2009, at 16:14, Kassen wrote:
Though some older protocols like SCSI have advantages over more modern, consumer friendly ones like USB, I don't there are any system bus issues for these, as one has some intermediate hardware that provides the communication. In the 1970s I assembled a computer, that wrote the keyboard characters directly into memory, which the CPU checked in a loop. This is highly inefficient way to handle it.
Ah, yes, I would indeed imagine that would be fast. For all I know that's what Apple is doing now...
A development now is that the GPus become usable as extra CPUs.
This might also be limited by factors like maximum poll-rate and resolution;
For the USB keyboards I have checked, this seems to be limitation of the keyboard, that is, even before the data is sent to the computer. This is because it differs with the keyboard. The computer is so fast that it easily can handle any human typed key roll-over. The slow USB 1 bus is on about 12 Mb/s, which should admit for tens of thousands of key stroke in a tenth of a second.
I meant PS/2 might be limited there.
Oh, I thought you meant the other way around.
In recent years the quality of high performance mice has gone up quite a bit, probably originally inspired by games like Quake. It was chiefly mouse signals that I was refering to.
I haven't checked that out.
Sadly (I feel) the quality of keyboards hasn't made the same progression and keyboard ghosting is now typically worse then it was on keyboards from the 80's.
On the Mac side, this was a problem in the 1990s - they would wear out after awhile - but not lately.
I think I tried a Mac keyboard once on a Windows, finding it not working. One needs to have a driver installed. Each device may require its own. The USB HID interface unifies those, so that only one driver is needed, which then can be supplied by the OS. The latest version of this USB HID interface or standard was issued this year. So perhaps it was not available when 'chuck' was written.
Odd. I've never seen a keyboard not work, I think. Special keys (like volume or "sleep" ones) may need a driver in my experience but the keyboard itself always worked. I think you can even take a ps/2 keyboard, use a USB adapter and plug it straight into a Mac, provided you are willing to remap some stuff to the "Apple" and related keys.
Windows is notorious for letting users install drivers on their own. On Mac OS X, they are usually supplied with the OS installation ("plug and play"). One exception was printer drivers when the Intel Macs were new - then, for awhile, they were only supplied with the OS installation on the PPC side. But when I looked on the Spacenavigator there was an article, in 2007 perhaps, about how to get it working on a Mac by finding some USB numbers. So this unified HID interface may be rather new. The USB HID key number assignment is also different an older and a newer Mac keyboard I have. The numbers of key above the <tab> and the key to the right of <left-shift> are swapped, I think it was. You might try those keys in the diatonic.ck I made - they are made for the more recent keyboard from 2009, which is the same as on a third one from 2002. So for correct translation, one needs to look up the name of the device, and choose a key map for that one. also, the Mac short keyboards have a special "function" key, that lets one to supply some of the keys of an extended keyboard, plus some for special Mac use. The function key was not reported at all, and pressing it did not report the extended keyboard key values. So it has some USB function not covered by the HID standard, it seems. Hans
Hans;
In recent years the quality of high performance mice has gone up quite a
bit, probably originally inspired by games like Quake. It was chiefly mouse signals that I was refering to.
I haven't checked that out.
It can become relevant when using a mouse as a general purpose sensor, for example to scan a turntable platter's rotation. In that case more resolution and a higher poll rate will lead to a more expressive instrument.
Sadly (I feel) the quality of keyboards hasn't made the same progression
and keyboard ghosting is now typically worse then it was on keyboards from the 80's.
On the Mac side, this was a problem in the 1990s - they would wear out after awhile - but not lately.
Sorry, but I haven't yet seen a keyboard that I liked as much as the old IBM Model M's. This is -of course- largely a matter of personal taste and application.
Windows is notorious for letting users install drivers on their own.
I have to say that I don't see any harm in that. We can't expect a OS maker to know ahead of time what sort of exotic devices and cards we'd like to add to our computer. I do agree that standard devices are a big leap up, with most things I can throw out the manual and discs and simply plug it in, expecting it to work. Good thing too as I don't like manuals and discs that much. If your mouse or webcam needs a manual it could probably do with a severe redesign, I feel. also, the Mac short keyboards have a special "function" key, that lets one
to supply some of the keys of an extended keyboard, plus some for special Mac use. The function key was not reported at all, and pressing it did not report the extended keyboard key values. So it has some USB function not covered by the HID standard, it seems.
Yes, I think those are a exception. I have a "fn" key on this laptop's keyboard as well, it deals with things like screen brightness, sleep/suspend, locking and so on. The strange thing is that ChucK doesn't register it as a HID key. We might initially suspect that it would talk to the hardware directly for things like screen brightness but the OS (Linux in this case) is clearly aware of it as it -for example- shows a little meter to indicate the change in brightness. Maybe it's the actual function (brightness, locking, etc) that is linked to a "keypress" and the OS might be unaware of there not being a single dedicated key for those. Especially with the way some laptops deal with NumLock that approach might lead to greater compatibility, I'm not sure, but that could still be according to the standard. Yours, Kas.
On 18 Jul 2009, at 20:26, Kassen wrote:
In recent years the quality of high performance mice has gone up quite a bit, probably originally inspired by games like Quake. It was chiefly mouse signals that I was refering to.
I haven't checked that out.
It can become relevant when using a mouse as a general purpose sensor, for example to scan a turntable platter's rotation. In that case more resolution and a higher poll rate will lead to a more expressive instrument.
That is an interesting use. If one does not have a turntable to scratch, I checked one can use the top of a matte CD or DVD - I only tried without print, and the underside (that carries the data) didn't work. So that might serve as an interface to scratch some audio-file There are laser turntables, but they are pretty expensive, and I don't know if they can be scratched: http://www.elpj.com/
Sadly (I feel) the quality of keyboards hasn't made the same progression and keyboard ghosting is now typically worse then it was on keyboards from the 80's.
On the Mac side, this was a problem in the 1990s - they would wear out after awhile - but not lately.
Sorry, but I haven't yet seen a keyboard that I liked as much as the old IBM Model M's. This is -of course- largely a matter of personal taste and application.
These are called "extended keyboards", or full size, at least on the Mac side http://en.wikipedia.org/wiki/Model_M_keyboard I have an old Mac one, where the function keys are without gaps and no space the other keys. This was very good for the diatonic key map, as it becomes enlarged. But I found it difficult to do ornaments on it: the keys are a bit too chevy. It is A1048 here: http://en.wikipedia.org/wiki/Apple_Keyboard#Apple_Keyboard I have for couple of months used the A1242 - it is much better on ornaments, but not as good as a musical instrument. The rather short action takes some time to get used to. The large one might still be good for playing bass.
Windows is notorious for letting users install drivers on their own.
I have to say that I don't see any harm in that. We can't expect a OS maker to know ahead of time what sort of exotic devices and cards we'd like to add to our computer. I do agree that standard devices are a big leap up, with most things I can throw out the manual and discs and simply plug it in, expecting it to work. Good thing too as I don't like manuals and discs that much. If your mouse or webcam needs a manual it could probably do with a severe redesign, I feel.
There was a adding cards to the computer also on the Mac, but they are mostly gone now, because the CPU/GPU are so powerful, it is not needed.
also, the Mac short keyboards have a special "function" key, that lets one to supply some of the keys of an extended keyboard, plus some for special Mac use. The function key was not reported at all, and pressing it did not report the extended keyboard key values. So it has some USB function not covered by the HID standard, it seems.
Yes, I think those are a exception. I have a "fn" key on this laptop's keyboard as well, it deals with things like screen brightness, sleep/suspend, locking and so on. The strange thing is that ChucK doesn't register it as a HID key. We might initially suspect that it would talk to the hardware directly for things like screen brightness but the OS (Linux in this case) is clearly aware of it as it -for example- shows a little meter to indicate the change in brightness. Maybe it's the actual function (brightness, locking, etc) that is linked to a "keypress" and the OS might be unaware of there not being a single dedicated key for those. Especially with the way some laptops deal with NumLock that approach might lead to greater compatibility, I'm not sure, but that could still be according to the standard.
This is what the driver would do. A pure HID device might not need a special driver, as the OS might supply a generic one. One reason to avoid custom supplied drivers is that they do low level things that may cause the computer to crash. On Macs, that is called "kernel panic". Basically, it means that the kernel running the processes gets some code that it cannot handle. Often, there is a driver for a piece of hardware involved. The hardware, the OS and the computer, though, are fine. Hans
I frequently use 'top -uR' (or 'top -ocpu -R' or 'top -ocpu -R -n10') to figure out if there are any CPU hogs. This program can itself also consume a lot of CPU power, relatively, on a slow machine. Hans
participants (3)
-
Hans Aberg -
Kassen -
Spencer Salazar