Jarod Wilson | 1 Jan 06:48 2010

Re: upcoming imon driver split

On Wed, Dec 30, 2009 at 06:32:00PM +0100, Christoph Bartelmus wrote:
> Hi!
> 
> In general I just dislike moving to a new interface loosing functionality.
> If possible I'd like to keep the possibility to get the raw scancodes  
> through the lirc interface.

Hrm. Two possibilities then...

1) I tack lirc support back in on top of this pure input layer imon
driver. I'd do this *after* getting lirc_dev also merged upstream
though, as this new driver should get in Real Soon Now.
2) We just keep lirc_imon with support for the newer devices as
something that can still be built/enabled (a la lirc_atiusb vs.
ati_remote{,2}).

> Even though there is a input driver for the ati remotes in the kernel for  
> a long time I have the impression that many people still prefer to use the  
> lirc_atiusb driver.

Well, as far as I can tell, that's mostly due to lack of understanding
of how the devinput usespace driver works. With mouse event passthrough,
there isn't any loss of functionality using the lirc devinput driver
with ati_remote{,2} vs. lirc_atiusb. I know I haven't bothered with
lirc_atiusb myself in ages for my RWII.

Honestly though, I'm not sure how much real benefit there is for the
imon driver to pass raw scancodes anymore, I think we've got everything
for the current devices pretty well covered, and new devices will
require code addition anyway. And the driver will spit out the raw
(Continue reading)

Jarod Wilson | 1 Jan 06:51 2010

Re: mceusb2, single transmitter works

On Tue, Dec 29, 2009 at 05:46:30PM +0000, Rajil Saraswat wrote:
> I am facing this issue again. The IR1 port is failing on two new
> devices which i am trying to setup. IR2 is working well. First is a
> Topseed (1784:0001) and the second is philips (0471:060c). The lirc
> version is from CVS and does have the Topseed and Philips defined in
> usb_device_id transmitter_mask_list[]
> 
> I am invoking lircd using "lircd -n -d /dev/lirc0
> remotes/mceusb/lircd.conf.mceusb". Unfortunately, i dont have physical
> access to the computer on which a similar philips device was working.
> 
> Are there any logs which i can provide to solve this problem?

Hrm. Nothing I'm aware of. Seems to me perhaps a modparam to set normal
or inverted transmitter mask might be nice as a debugging aid. Not sure
how all the entries in the inverted list got there (i.e., if they've all
been verified). Would kinda suck if there were actually devices with the
exact same ID that had different masks...

--

-- 
Jarod Wilson
jarod@...

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 

(Continue reading)

Christoph Bartelmus | 1 Jan 11:38 2010
Picon

Re: mceusb2, single transmitter works

Hi!

Jarod Wilson "jarod@..." wrote:

> On Tue, Dec 29, 2009 at 05:46:30PM +0000, Rajil Saraswat wrote:
>> I am facing this issue again. The IR1 port is failing on two new
>> devices which i am trying to setup. IR2 is working well. First is a
>> Topseed (1784:0001) and the second is philips (0471:060c). The lirc
>> version is from CVS and does have the Topseed and Philips defined in
>> usb_device_id transmitter_mask_list[]
>>
>> I am invoking lircd using "lircd -n -d /dev/lirc0
>> remotes/mceusb/lircd.conf.mceusb". Unfortunately, i dont have physical
>> access to the computer on which a similar philips device was working.
>>
>> Are there any logs which i can provide to solve this problem?

> Hrm. Nothing I'm aware of. Seems to me perhaps a modparam to set normal
> or inverted transmitter mask might be nice as a debugging aid. Not sure
> how all the entries in the inverted list got there (i.e., if they've all
> been verified).

I'm pretty sure that some entries have just been a guess. At best based on  
how other models from the same manufacuturer behaved.
If CVS log does not say otherwise I'd just do changes if they have been  
verified to work.

Christoph

------------------------------------------------------------------------------
(Continue reading)

Christoph Bartelmus | 1 Jan 11:33 2010
Picon

Re: upcoming imon driver split

Hi!

Jarod Wilson "jarod@..." wrote:
[...]
> Honestly though, I'm not sure how much real benefit there is for the
> imon driver to pass raw scancodes anymore,

I'll tell you.
On my current laptop I'm using Debian Lenny now. On the very same laptop  
I've been running all Debian versions back from Slink.
Every time I do an upgrade I spend countless hours because there have been  
some interface changes here and there which need manual adjustment. No  
matter how much effort packagers may be putting into this, it never just  
works. Last upgrade left me with a crashing X on startup.
Was fun to google this, while lynx was showing black text on black  
background in console because some change in config syntax...
This sucks!

I'm not saying that we should keep legacy code everywhere, but in cases  
where it's so easy to have the old behaviour I'd just keep it.

And I know that for you it's easy to load the module in debug mode and add  
new keycodes, but that's not what the average user can do.

Christoph

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
(Continue reading)

Vojtech Pavlik | 2 Jan 09:08 2010
Picon

Re: lircd uinput support broken by xf86-input-evdev-2.3.1

On Thu, Dec 31, 2009 at 01:35:00PM +0100, Christoph Bartelmus wrote:
> Hi Vojtech,
> 
> on 31 Dec 09 at 13:05, Vojtech Pavlik wrote:
> > On Thu, Dec 31, 2009 at 10:56:00AM +0100, Christoph Bartelmus wrote:
> 
> >>> Based on a patch to a similar bug on Gentoo
> >>> (http://bugs.gentoo.org/show_bug.cgi?id=298459), I created a patch
> >>> (attached) for lircd that causes it to send an EV_SYN event after
> >>> sending an EV_KEY event.  With this patch, my setup is working once
> >>> again.
> >>>
> >>> So, is this the proper fix?
> >>
> >> No idea. I can't find any useful documentation on the input interface.
> >> All programming I've done on that is more or less trial'n'error.
> >>
> >> Maybe Vojtech can clarify.
> 
> > Yes, this sounds right - the input core only signals the availability of
> > data to the reader process after the EV_SYN/SYN_REPORT event is placed
> > into the queue.
> 
> Does that mean that lircd when simulating input events through uinput also  
> must generate EV_SYN events?

Yes, of course. A SYN_REPORT needs to be send everytime a update of
state information from a device has been completed.

> In this case it seems that newer versions of X rely on EV_SYN and wait for  
(Continue reading)

Magnus Ottosson | 3 Jan 10:35 2010
Picon

Re: Lirc and Apple Remote

Hi,

I have recorded the signals recieved using: sudo mode2 -d /dev/lirc0

You can see the result here:
http://spreadsheets.google.com/ccc?key=0AvTiMdLE7NyrdDd1RlBuVnhxSXhZTmMtT2tMM2pSdEE&hl=en

Each button has been recorded three times. Anyone who could help me to
create a config for this remote?

//Magnus

On Tue, Dec 29, 2009 at 1:52 PM, Magnus Ottosson
<magnus@...> wrote:
> Hi,
>
> I just bought an apple remote: http://store.apple.com/us/product/MC377LL/A
>
> I wan't to use this on with a generic ir reciever on my asus eb1012.
>
> The reciever belongs to a generic windows media center remote and that
> is working perfekt.
>
> I have been trying to create a lirc config for the apple remote and
> here is where my problem starts. It seems like the remote is
> "unstable" and a press on the meny button sends different codes
> depending on which button I have pressed before.
>
> I used dmode2 to analyse the codes recieved from the remote and I do
> recieve codes but they are different from time to time. It is possible
(Continue reading)

Dom H | 6 Jan 11:37 2010

Re: Help diagnosing non-responsive receiver

Well I've solved the issue but I am utterly confused what the problem was.

I booted an XP virtual machine in VirtualBox and enabled the Mplay USB
device for the guest OS and installed the windows drivers from the
Zalman CD download. Now, the serial driver installed fine but the
Zalman software couldn't find the device BUT eventually the IR LED
went out (flicking on with each button push as before) and after
rebooting the remote functioned as before with LIRC

How can the device get into such a state that isn't reset with a long
power off and what put it into this state in the first place??

Thanks

2009/12/29 Dom H <speedsix.lists@...>:
> Hi all,
>
> I have a Zalman HD135 case with an integrated VLSystem Mplay Blast
> VFD/Remote (usb with FTDI serial converter). Somehow over the past
> couple of days, while trying to sort issues with the display which had
> stopped working (installing newer LCDproc) I have somehow managed to
> stop the IR functioning completely. As soon as I power up the machine
> the IR light on the display is permanently lit (I have seen it do this
> before but now it's stuck like this)
>
> I cannot get any response from the IR portion even though the display
> works perfectly with LCDproc (both via /dev/ttyUSB0). Lirc starts as
> if everything is ok but receives no inputs, irrecord the same. I've
> tried turning the power off for a long period but it seems to be stuck
> or it in fact faulty.
(Continue reading)

mnrdk | 5 Jan 14:50 2010
Picon

Re: SV: problems with IMON Knob IR receiver


Jarod Wilson wrote:
> 
> Those are the wrong codes, you need:
> 
>           KEY_UP                   0x01008000 # Pad Up
>           KEY_DOWN                 0x01007f00 # Pad Down
>           KEY_LEFT                 0x01000080 # Pad Left
>           KEY_RIGHT                0x0100007f # Pad Right
> 
> or possibly:
> 
>           KEY_UP                   0x2aa515b7 # Pad Up
>           KEY_DOWN                 0x289515b7 # Pad Down
>           KEY_LEFT                 0x29a515b7 # Pad Left
>           KEY_RIGHT                0x2ba515b7 # Pad Right
> 
> The Cursor{Up,Down,Left,Right} values in the config aren't valid anymore.
> I'll fix that now. What was in there before (and still is, just in case),
> was for the fabricated values generated by an old pad2keys patch, iirc. We
> now use some more standardized filtering and pseudo-code generating stuff
> (the first group of 4 above) and there are some imon remotes that actually
> have distinct arrow keys (the second group of 4 above).
> 

Sry for the late reply to this. Xmas and all...

I actually managed to make the pad work, but have not tried the codes you
have supplied. Will do that shortly.

(Continue reading)

Jarod Wilson | 6 Jan 22:51 2010

Re: SV: problems with IMON Knob IR receiver

On Jan 5, 2010, at 8:50 AM, mnrdk wrote:

> Jarod Wilson wrote:
>> 
>> Those are the wrong codes, you need:
>> 
>>          KEY_UP                   0x01008000 # Pad Up
>>          KEY_DOWN                 0x01007f00 # Pad Down
>>          KEY_LEFT                 0x01000080 # Pad Left
>>          KEY_RIGHT                0x0100007f # Pad Right
>> 
>> or possibly:
>> 
>>          KEY_UP                   0x2aa515b7 # Pad Up
>>          KEY_DOWN                 0x289515b7 # Pad Down
>>          KEY_LEFT                 0x29a515b7 # Pad Left
>>          KEY_RIGHT                0x2ba515b7 # Pad Right
>> 
>> The Cursor{Up,Down,Left,Right} values in the config aren't valid anymore.
>> I'll fix that now. What was in there before (and still is, just in case),
>> was for the fabricated values generated by an old pad2keys patch, iirc. We
>> now use some more standardized filtering and pseudo-code generating stuff
>> (the first group of 4 above) and there are some imon remotes that actually
>> have distinct arrow keys (the second group of 4 above).
>> 
> 
> Sry for the late reply to this. Xmas and all...
> 
> I actually managed to make the pad work, but have not tried the codes you
> have supplied. Will do that shortly.
(Continue reading)

Christoph Bartelmus | 7 Jan 22:26 2010
Picon

Re: lircd uinput support broken by xf86-input-evdev-2.3.1

Hi!

Vojtech Pavlik "vojtech@..." wrote:
[...]
>> In this case it seems that newer versions of X rely on EV_SYN and wait for
>> EV_SYN before processing input events.
>> I can't find any place where this requirement documented.

> linux/Documentation/input/input-programming.txt doesn't state it as a
> requirement, but I hope it's rather clear on the matter.

EV_SYN and SYN_REPORT are not even mentioned:
http://lxr.linux.no/#linux+v2.6.32/Documentation/input/input-programming.txt

Christoph

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 


Gmane