Logitech Dual Action USB
From an old thread on misc@, circa Jun 17, 2008: Re: usb gamepads So I ended up bying a Logitech Dual Action for $15 at a local store. This is what shows up in dmesg: uhidev2 at uhub1 port 2 configuration 1 interface 0 Logitech Logitech Dual Action rev 1.10/3.00 addr 2 uhidev2: iclass 3/0 uhid0 at uhidev2: input=8, output=7, feature=5 All the buttons and analog sticks work okay. I tried it with bzflag, zsnes and generator (r3, the r2 package didn't work with it). I was also going to try xmame, but the compile bombed and I didn't spell FLAVOR correctly anyway (used the british spelling... oops). Well anyway it's a nice piece of hardware for the price! -- Stephen Takacs perlhaq@... http://perlguru.net/ 4149 FD56 D078 C988 9027 1EB4 04CC F80F 72CB 09DA Does anyone still have one of these working? Recent snapshots produce only this in dmesg: uhub1: port 1, set config at addr 2 failed uhub1: device problem, disabling port 1 -sl
Re: Logitech Dual Action USB
From an old thread on misc@, circa Jun 17, 2008: Re: usb gamepads So I ended up bying a Logitech Dual Action for $15 at a local store. This is what shows up in dmesg: uhidev2 at uhub1 port 2 configuration 1 interface 0 Logitech Logitech Dual Action rev 1.10/3.00 addr 2 uhidev2: iclass 3/0 uhid0 at uhidev2: input=8, output=7, feature=5 All the buttons and analog sticks work okay. I tried it with bzflag, zsnes and generator (r3, the r2 package didn't work with it). I was also going to try xmame, but the compile bombed and I didn't spell FLAVOR correctly anyway (used the british spelling... oops). Well anyway it's a nice piece of hardware for the price! -- Stephen Takacs perlhaq@... http://perlguru.net/ 4149 FD56 D078 C988 9027 1EB4 04CC F80F 72CB 09DA ... [show rest of quote] Does anyone still have one of these working? Recent snapshots produce only this in dmesg: uhub1: port 1, set config at addr 2 failed uhub1: device problem, disabling port 1 On a different system, the controller is at least recognized: uhidev1 at uhub2 port 1 configuration 1 interface 0 Logitech Logitech Dual Action rev 1.10/3.00 addr 2 uhidev1: iclass 3/0 uhid21 at uhidev1: input=8, output=7, feature=5 but does not work in bzflag or pcsx. -sl
Re: qemu-old .. relevent or not?
I've gotten one request to decommission qemu-old. It surprised me, as I thought there were still issues with qemu/ even with the semi recent thread fix as well as performance differences. Does anybody have objection to retiring qemu-old to the attic or ? I'd rather not do this prematurely but if the time has come, this is the right time of release cycle to do it. I'm probably less educated about the functionality of newer qemu than I should be, but I still use the old version from ports (along with kqemu) to host Plan 9 on various systems. My understanding is that moving to the newer version(s) of qemu would introduce a performance hit, since kqemu is deprecated and whatever newer, fancier kernel integration has been introduced is not yet supported on OpenBSD. Is this wildly off-base? -sl
Re: qemu-old .. relevent or not?
On Mon, Mar 21, 2011 at 5:53 PM, Brad b...@comstyle.com wrote: On 22/03/11 4:54 PM, Stanley Lieber wrote: I've gotten one request to decommission qemu-old. B It surprised me, as I thought there were still issues with qemu/ even with the semi recent thread fix as well as performance differences. Does anybody have objection to retiring qemu-old to the attic or ? I'd rather not do this prematurely but if the time has come, this is the right time of release cycle to do it. I'm probably less educated about the functionality of newer qemu than I should be, but I still use the old version from ports (along with kqemu) to host Plan 9 on various systems. My understanding is that moving to the newer version(s) of qemu would introduce a performance hit, since kqemu is deprecated and whatever newer, fancier kernel integration has been introduced is not yet supported on OpenBSD. Is this wildly off-base? KQEMU is an unsupported piece of code that no one has ever maintained, doesn't work on MP kernels and has issues even on SP kernels. It's not deprecated. It is plain dead, period. No one cared to actually fix it when the QEMU developers asked on their list for the OS's that actually used it (*BSD, Solaris) and later some of its design limitations prevented further progress so support was removed all together. Taking that out of the picture and doing an apples to apples comparison can you find any real issues between the versions of QEMU that have a real effect on your Plan 9 images? No experimental evidence, yet, but I'm willing to give it a shot. Subjectively, the old qemu feels quite a bit slower without kqemu. I'll do some testing. -sl
