Anyone got joystick working with hardware 0xffdc

[Tobo]

First of all, tnx for the drivers venky, great job!!!

Then for my problem;

Im using the complete driver set for lirc/VFD and this is working great for my hardware (device 0xffdc). Everything working satisfactory except for the joystick. I can record a config for this and merge with the lircd.conf supplied by venky and this works but joystick output is sporadic. Sometimes it works, sometimes it don't. Sometimes it "hangs" until you press another button on the remote and sometimes it sends event without me pressing the joy...

Anyone got a config example working with the joystick. If so please post it or tell me about your experience...

Tnx again venly!

[Venky]

Hi Tobo,
Thank you for your comments! Do you have the iMON RSC remote or the PAD remote?

The joystick in the iMON RSC remote is supported but the joystick in the iMON PAD remote is more like a mouse and not a 16-position stick like the RSC. I haven't found time to decipher the protocol yet and I probably will not get to it for at least a couple of months.

Venky

[DataPath]

Venky: I've been looking it the PAD remote's output, and thus far, it looks like it's pressure sensitive - push lightly, and you get one value, push harder and you get another.

I'm working on it right now, so I'll pass on more as I learn more.

[DataPath]

It looks like there are 10 levels of sensitivity, and I think just 8 directions, but I'm not entirely sure.

Venky: in the lircd.conf you provided for the PAD remote, you have a line that says post_data 0xB7. I think that means that each remote command is followed by the 8 bit sequence B7, and just ignore it.

If I'm reading that right, that's a problem, because the mouse pad actually changes that value as far as I can tell.

edit: it appears that you can get BF to appear in place of B7 with any button, but infrequently - no clue why, but it doesn't appear to be often enough to matter.

edit #2: and it looks like there's a whole heck of a lot more than 8 directions. *sigh*. I stand by my statement that there are 9 levels of sensitivity - pay no attention to the man behind the curtain saying there are 10.

[Venky]

DataPath,
Congratulations on deciphering the PAD function! BTW I removed the post_data in the config file I submitted to CVS.

Venky

[DataPath]

My goodness this thing is complex - I'm looking at what happens when you press down "left click" or "right click" at the same time as "moving the mouse".

The values the mouse puts out depend on the state of left click and right click

A mouse action is indicated by 0x400000 bit being on.

If the (value & 0x180) == 0x100, then the left mouse button is depressed
If the (value & 0x600) == 0x400, then the right mouse button is depressed

I think the pad works on the principle of X-axis Y-axis, but I'm still working that out.

[DataPath]

DataPath,
[snip]
BTW I removed the post_data in the config file I submitted to CVS.

Venky

Seeing as how infrequently the BF sequence comes up, I think it might be best to leave the post_data 0xB7 in there, until we understand what the heck it means.

[DataPath]

Got it!

There is a bit for X+/X-, and a bit for Y+/Y-, and there are 4 magnitude bits for each axis - but they're in reverse order!

So the mask to determine if it's a mouse action is 0x400000
The mask for the R. Click button is 0x600
The mask for the L. Click button is 0x180
The mask for the X Sign Bit is 0x20000
The mask for the Y Sign Bit is 0x10000
The mask for X Magnitude is 0x7800
The mask for Y Magnitude is 0x78

So each axis is a signed 5-bit integer, calculated like this:

Code: Select all

/* reversing the bits in the magnitude */
if(backwards_magnitude & 0x01) forward_magnitude |= 0x08;
if(backwards_magnitude & 0x02) forward_magnitude |= 0x04;
if(backwards_magnitude & 0x04) forward_magnitude |= 0x02;
if(backwards_magnitude & 0x08) forward_magnitude |= 0x01;
/* add in the sign bit, and sign extend */
/* 0x10 is where the sign bit belongs in the final value */
/* ~0x10 + 1 is the two's complement in order to sign extend it */
if(sign_bit) forward_magnitude |= ~0x10 + 1;


the pad is pressure sensitive, and non-linear, so the possible values that result from this are:
-14
-12
-10
-7
-5
-4
-3
-2
-1
0
1
2
3
4
5
7
10
12
14

[Venky]

Excellent work, DataPath! I will confirm this on my PAD in a couple of days.

Venky

[lenn0x]

Have you tested this? I recently purchased a Silverstonetek LC11M and I believe the pad thats on that remote control is the same you guys are trying to get working

[Clif4D]

DataPath, I have looked into your findings, and I can confirm almost all of them, one thing is bothering me though, if I OR all your masks for the active bits together, I get the following: 0x37FF8 (binary 00000110111111111111000)

As far as I can see, the first 5 bits and last 3 are static for the mouse commands. I believe this is correct as I have captured more than 358 of the 1444 possible commands (19 x 19 gridpoints and 4 possible button states; none, left, right, both) but the bit in between the "x/y sign" bits, and the "y-magnitude" bits seems to change when I use the nothern part of the pad, and I just though you should know if you're going to write a mouse driver for the pad.

To clearify your posted mask, here are the binary masks and possible states, when disregarding the last 8 bits, which are always BF/B7 for all commands:

right mouse button: 000000000000xx000000000 01 = "off", 10 = "on"

left mouse button: 00000000000000xx0000000 01 = "off", 10 = "on"

y-magnitude: 0000000000000000xxxx000
Nothern direction: reverse bit order and reverse direction (light push gives bigger value)
Southern direction: reverse bit order (light push gives smaller value)

x-magnitude: 00000000xxxx00000000000
East: reverse bit order (light push gives smaller value)
West: reverse bit order and reverse direction (light push gives bigger value)

y-sign bit: 000000x0000000000000000 1 = north, 0 = south, however as stated, the previous bit also gets cleared when pressing north direction.

x-sign bit: 00000x00000000000000000 1 = west, 0 = east

static bits: 11010xxxxxxxxxxxxxxx001

puzzle bit: 0000000x000000000000000 as far as I can see it has got something to do with the nothern direction.

Hope this helps in any way, since it would be great to get a mouse driver working for this device.

[DataPath]

That's exactly what I got in my testing, right down to the puzzle bit.

There's a bit in the top byte that I call the "mouse bit", because it is on ONLY for mouse commands (including l. click and r. click), off for all other buttons.

I've got the mouse driver part written, I just need to test and debug it. I did test it once, got nothing, so I know there's debugging to do, I just don't know exactly what yet. I know that I intercept all mouse commands, while passing the others on through - lirc echos all button presses except for mouse ones. But the input system doesn't acknowledge the commands, and my printk statements aren't printing anything that I can find.

[pivert]

Hello !!

Any news about the status of the "PAD mouse" ?

Regards,

That's exactly what I got in my testing, right down to the puzzle bit.

There's a bit in the top byte that I call the "mouse bit", because it is on ONLY for mouse commands (including l. click and r. click), off for all other buttons.

I've got the mouse driver part written, I just need to test and debug it. I did test it once, got nothing, so I know there's debugging to do, I just don't know exactly what yet. I know that I intercept all mouse commands, while passing the others on through - lirc echos all button presses except for mouse ones. But the input system doesn't acknowledge the commands, and my printk statements aren't printing anything that I can find.

[DataPath]

My thoughts for the right way to do this have changed.

I posted a patch to the forum that works quite well, but at the moment I have no plans to do further development on it.

I feel that adding in a special case to the lirc_imon driver is the wrong way to do it simply because you can use almost any TV/VCR/DVD/Stereo remote in the world with the lirc_imon driver, and you can create configuration files to support each and every one.

I've been thinking, but haven't yet come up with what I feel is the "right" solution.