Re: Combining lirc0 and lirc1 on current iMON hardware

[Jarod W. <ja...@wi...>]

On Jun 16, 2009, at 12:39 AM, Rene Harder wrote:

> Hi Jarod,
>
> First of all, you did an outstanding job, i compiled the driver and  
> the
> touchscreen was working quite fine.

Woo! :)

Unfortunately, it doesn't seem to be working quite as well on the ffdc  
devices yet...


> Well after i figured out that the
> lirc device needs to be opened before it's working.

Yeah, I should probably mention that somewhere...


> I've added a patch with two minor changes.
> The first on adds touchscreen support for the 4.3" (15c2:0035) model.
> Soundgraph changed one byte for this model.

Figures...

Applied (with some formatting differences -- trying to keep to 80 char  
or less lines).

> The second one solves a compile error which occurred after your last
> changes.

Gah. I was wondering where this stray int err; came from, neglected to  
compile test after killing it off. I must have screwed up an insert in  
an earlier commit. Thanks for the fix. Applied, though  by putting int  
err; back where it originally was.


> There are still some minor bugs related to the touchscreen:
>
> The touchscreen and mouse input only works if the lirc device is  
> open. I
> guess that should be solvable with moving the input event code into  
> the
> usb_rx_callback_xxx functions.

Nope, it fails just the same in there, at least right now. If IR isn't  
open, the urb's aren't set up and the callbacks won't fire (ir_open  
does usb_fill_int_urb() calls, ir_close does usb_kill_urb()). So I  
guess we'd have to move the urb setup into imon_probe() and the  
teardown into imon_disconnect() if we want mouse and touchscreen  
operable w/o IR open.

Even then, it gets... messy. We'd need to check for all the mouse  
stuff in the intf0 callback, while its split between intf0 and intf1  
for the newer devices. I'm thinking perhaps a new function that is  
designed specifically for handling input device packets, called from  
both intf0 and intf1 callbacks, to keep code duplication to a  
minimum... Okay, this might not actually be too bad...


> If you touch the screen before the lirc device is open. Once you open
> the device the X server gets confused. X probably does not receive the
> touch release bit  (generated by the timer callback function) and sets
> the mouse button as clicked but not released, you need to unload the
> driver before it'll work normal again. If the input event generation  
> is
> independent on the status of the lirc device this will be solved as  
> well.

Ick. I need me one of these devices, would make it much easier to work  
on the code... :) I'll be leaning heavily on you here.


> For the iMONs with touchscreen there are at least 2 remotes with
> different mouse toggle button codes. One you have already implemented,
> for the other one the 3. byte is 0x35 instead of 0x15.

I thought the 0x15 code was "button pressed" and the 0x35 code was  
"button released". But in looking back over my notes, I'm not so  
sure... I have a 'spews 0x0100007f between press and release' note  
here and '"no longer pressed" is key | 0x00004000'. Ugh. I'll poke more.

In related news, I tried pinging soundgraph for some docs or  
something. Nothing but silence. Not exactly surprised though, I've  
heard they've been entirely uncooperative in the past too.


-- 
Jarod Wilson
ja...@wi...