Linux Infrared Remote Control

Email Archive: lirc-list (read-only)

Re: more lirc_mceusb

From: Dan Conti <dconti@ac...> - 2004-12-10 06:04

Hi,

I haven't been monitoring this list for a bit, so i apologize for people
who have had this problem and been confused. I have gotten a couple of
off-list inquiries which i looked at for a bit.

What is going on here is, unfortunately, MS and phillips have elected to
change the remotes used for MCE 2005. It looks like this is just a
change on the internals though, and the external housing and usb
transceiver are the same.

The result is that the protocol for the remotes is completely different;
this is why the mceusb_setup lines are printing out bad result codes.
The user experience isn't that good on this because, well, the driver
isn't designed to have the wrong product and vendor id's thrown in there.

If people who are having lirc_mceusb problems could verify that the
remote you purchased looks exactly like this:

http://www.pcalchemy.com/images/philips/philips-mce-remote.jpg

That would be helpful. Naturally the bad news is that people looking to
purchase these remotes may have no way of telling whether they are
getting the older, microsoft version (which the driver supports) or the
newer, phillips version (which it does not).

For lirc, the solution will be to analyze the data the new usb
transceiver expects and provides on the bus; it is possible that this is
very similar, but not identical to the previous transceiver. If someone
is interested in doing this, you are welcome to contact me regarding the
original driver. It is also possible the protocol is completely
different, and may warrant writing a new driver.

For users who have this remote, the solution is to either a) wait for
lirc to be updated to support the transceiver, or b) investigate
building a homebrew receiver.

Thanks,
-Dan

Wayne Vosberg wrote:
> I hope someone is still working on this driver and will be able to point me in
> the right direction. I have a generic Phlips USB MCE remote:
>
> # lsusb -vvs 1:6
>
> Bus 001 Device 006: ID 0471:0815 Philips
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 1.10
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 16
> idVendor 0x0471 Philips
> idProduct 0x0815
> bcdDevice 0.00
> iManufacturer 1 Philips
> iProduct 2 eHome Infrared Transceiver
> iSerial 3 PH0018VA
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 32
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xa0
> Remote Wakeup
> MaxPower 100mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 255 Vendor Specific Subclass
> bInterfaceProtocol 255 Vendor Specific Protocol
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x01 EP 1 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type none
> Usage Type Data
> wMaxPacketSize 0x0010 bytes 16 once
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type none
> Usage Type Data
> wMaxPacketSize 0x0010 bytes 16 once
> bInterval 0
> Language IDs: (length=4)
> 0409 English(US)
>
> I modified the source to include my Vendor/Product IDs:
> /*
> #define USB_MCEUSB_VENDOR_ID 0x045e
> #define USB_MCEUSB_PRODUCT_ID 0x006d
> */
> #define USB_MCEUSB_VENDOR_ID 0x0471
> #define USB_MCEUSB_PRODUCT_ID 0x0815
>
> and everything compiles, starts and seems to run fine, except that
> neither irw nor irrecord ever see a button push.
>
> Here is the debug output from lirc_mceusb startup:
>
> lirc_dev: IR Remote Control driver registered, at major 61
> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk out endpoint
> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk in endpoint
> lirc_dev: lirc_register_plugin:sample_rate: 80
> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res
> = 2 status = 0x1 0x0
> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res
> = -32, devnum = 6
> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
> data[0] = 0, data[1] = 0
> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res = -32
> usbcore: registered new driver lirc_mceusb
>
> I suspect that -32 return from:
>
> res = usb_control_msg( udev, usb_rcvctrlpipe(udev, 0),
> 5, USB_TYPE_VENDOR, 0, 0,
> data, 2, HZ * 3 );
>
> is incorrect. Any idea on where to go from here?
>
> TIA
> Wayne Vosberg
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
>

Thread View

Thread	Author	Date
more lirc_mceusb	Wayne Vosberg <wayne.vosberg@gm...>

Re: more lirc_mceusb

From: Dan Conti <dconti@ac...> - 2004-12-10 06:04

Re: more lirc_mceusb

From: Jonathan Mills <jonmills@em...> - 2004-12-10 06:34

Attachments: Message as HTML

I would just like to say that exactly TWO days ago, I sent a message to
this list in which I explicitly asked whether or not THIS EXACT PHILIPS
REMOTE would work with LIRC.

I got no real response, and figured people were ignoring me because it
must have been a dump question. I started googling and, sure enough,
found many instances where people were successfully using the "MCE
Remote" with LIRC.

Satisfied with this info, I bought the Philips MCE remote from NewEgg.

Now I see that my new remote, which I haven't even received from FedEx
yet, isn't going to work with LIRC, unless I suddenly develop some
programming skills over the weekend.

Thanks everyone for the feedback.

Sincerely,

Frustrated Newbie

Dan Conti wrote:

> Hi,
>
> I haven't been monitoring this list for a bit, so i apologize for
> people who have had this problem and been confused. I have gotten a
> couple of off-list inquiries which i looked at for a bit.
>
> What is going on here is, unfortunately, MS and phillips have elected
> to change the remotes used for MCE 2005. It looks like this is just a
> change on the internals though, and the external housing and usb
> transceiver are the same.
>
> The result is that the protocol for the remotes is completely
> different; this is why the mceusb_setup lines are printing out bad
> result codes. The user experience isn't that good on this because,
> well, the driver isn't designed to have the wrong product and vendor
> id's thrown in there.
>
> If people who are having lirc_mceusb problems could verify that the
> remote you purchased looks exactly like this:
>
> http://www.pcalchemy.com/images/philips/philips-mce-remote.jpg
>
> That would be helpful. Naturally the bad news is that people looking
> to purchase these remotes may have no way of telling whether they are
> getting the older, microsoft version (which the driver supports) or
> the newer, phillips version (which it does not).
>
> For lirc, the solution will be to analyze the data the new usb
> transceiver expects and provides on the bus; it is possible that this
> is very similar, but not identical to the previous transceiver. If
> someone is interested in doing this, you are welcome to contact me
> regarding the original driver. It is also possible the protocol is
> completely different, and may warrant writing a new driver.
>
> For users who have this remote, the solution is to either a) wait for
> lirc to be updated to support the transceiver, or b) investigate
> building a homebrew receiver.
>
> Thanks,
> -Dan
>
> Wayne Vosberg wrote:
>
>> I hope someone is still working on this driver and will be able to
>> point me in
>> the right direction. I have a generic Phlips USB MCE remote:
>>
>> # lsusb -vvs 1:6
>>
>> Bus 001 Device 006: ID 0471:0815 Philips
>> Device Descriptor:
>> bLength 18
>> bDescriptorType 1
>> bcdUSB 1.10
>> bDeviceClass 0 (Defined at Interface level)
>> bDeviceSubClass 0
>> bDeviceProtocol 0
>> bMaxPacketSize0 16
>> idVendor 0x0471 Philips
>> idProduct 0x0815
>> bcdDevice 0.00
>> iManufacturer 1 Philips
>> iProduct 2 eHome Infrared Transceiver
>> iSerial 3 PH0018VA
>> bNumConfigurations 1
>> Configuration Descriptor:
>> bLength 9
>> bDescriptorType 2
>> wTotalLength 32
>> bNumInterfaces 1
>> bConfigurationValue 1
>> iConfiguration 0
>> bmAttributes 0xa0
>> Remote Wakeup
>> MaxPower 100mA
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 0
>> bAlternateSetting 0
>> bNumEndpoints 2
>> bInterfaceClass 255 Vendor Specific Class
>> bInterfaceSubClass 255 Vendor Specific Subclass
>> bInterfaceProtocol 255 Vendor Specific Protocol
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x01 EP 1 OUT
>> bmAttributes 2
>> Transfer Type Bulk
>> Synch Type none
>> Usage Type Data
>> wMaxPacketSize 0x0010 bytes 16 once
>> bInterval 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x81 EP 1 IN
>> bmAttributes 2
>> Transfer Type Bulk
>> Synch Type none
>> Usage Type Data
>> wMaxPacketSize 0x0010 bytes 16 once
>> bInterval 0
>> Language IDs: (length=4)
>> 0409 English(US)
>>
>> I modified the source to include my Vendor/Product IDs:
>> /*
>> #define USB_MCEUSB_VENDOR_ID 0x045e
>> #define USB_MCEUSB_PRODUCT_ID 0x006d
>> */
>> #define USB_MCEUSB_VENDOR_ID 0x0471
>> #define USB_MCEUSB_PRODUCT_ID 0x0815
>>
>> and everything compiles, starts and seems to run fine, except that
>> neither irw nor irrecord ever see a button push.
>>
>> Here is the debug output from lirc_mceusb startup:
>>
>> lirc_dev: IR Remote Control driver registered, at major 61
>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk
>> out endpoint
>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk
>> in endpoint
>> lirc_dev: lirc_register_plugin:sample_rate: 80
>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res
>> = 2 status = 0x1 0x0
>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res
>> = -32, devnum = 6
>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
>> data[0] = 0, data[1] = 0
>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
>> res = -32
>> usbcore: registered new driver lirc_mceusb
>>
>> I suspect that -32 return from:
>>
>> res = usb_control_msg( udev, usb_rcvctrlpipe(udev, 0),
>> 5, USB_TYPE_VENDOR, 0, 0,
>> data, 2, HZ * 3 );
>>
>> is incorrect. Any idea on where to go from here?
>>
>> TIA
>> Wayne Vosberg
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://productguide.itmanagersjournal.com/
>>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/

Re: more lirc_mceusb

From: Dan Conti <dconti@ac...> - 2004-12-10 07:50

Nobody is saying it wont work; i am saying that it is possible it wont
work, since it appears that the new remotes are internally different
from the old ones, and to the consumer the differences are
indistinguishable. When i purchased my remote it was labeled as a
philips, even though the chip IDs as microsoft, and i too purchased mine
from newegg. It's possible you'll get what i have, which is what
everybody had up until 2-3 weeks ago, which is the original product;
then again, you might get the newer product.

If you are not keen on this situation, you should look into newegg's
return policy. Sorry, but there were emails on this list over the past
week with people having issues with the new remote, and there have been
emails in the past indicating that the transmit portion of the MS
transceiver may never be supported.

At the very least, i would wait until it arrives, plug in the
transciever, and see if the product/vendor id match the microsoft ones
used in the driver. No reason to be frustrated over a problem you might
not have.

Thanks,
-Dan

Jonathan Mills wrote:
> I would just like to say that exactly TWO days ago, I sent a message to
> this list in which I explicitly asked whether or not THIS EXACT PHILIPS
> REMOTE would work with LIRC.
>
> I got no real response, and figured people were ignoring me because it
> must have been a dump question. I started googling and, sure enough,
> found many instances where people were successfully using the "MCE
> Remote" with LIRC.
>
> Satisfied with this info, I bought the Philips MCE remote from NewEgg.
>
> Now I see that my new remote, which I haven't even received from FedEx
> yet, isn't going to work with LIRC, unless I suddenly develop some
> programming skills over the weekend.
>
> Thanks everyone for the feedback.
>
> Sincerely,
>
> Frustrated Newbie
>
> Dan Conti wrote:
>
>> Hi,
>>
>> I haven't been monitoring this list for a bit, so i apologize for
>> people who have had this problem and been confused. I have gotten a
>> couple of off-list inquiries which i looked at for a bit.
>>
>> What is going on here is, unfortunately, MS and phillips have elected
>> to change the remotes used for MCE 2005. It looks like this is just a
>> change on the internals though, and the external housing and usb
>> transceiver are the same.
>>
>> The result is that the protocol for the remotes is completely
>> different; this is why the mceusb_setup lines are printing out bad
>> result codes. The user experience isn't that good on this because,
>> well, the driver isn't designed to have the wrong product and vendor
>> id's thrown in there.
>>
>> If people who are having lirc_mceusb problems could verify that the
>> remote you purchased looks exactly like this:
>>
>> http://www.pcalchemy.com/images/philips/philips-mce-remote.jpg
>>
>> That would be helpful. Naturally the bad news is that people looking
>> to purchase these remotes may have no way of telling whether they are
>> getting the older, microsoft version (which the driver supports) or
>> the newer, phillips version (which it does not).
>>
>> For lirc, the solution will be to analyze the data the new usb
>> transceiver expects and provides on the bus; it is possible that this
>> is very similar, but not identical to the previous transceiver. If
>> someone is interested in doing this, you are welcome to contact me
>> regarding the original driver. It is also possible the protocol is
>> completely different, and may warrant writing a new driver.
>>
>> For users who have this remote, the solution is to either a) wait for
>> lirc to be updated to support the transceiver, or b) investigate
>> building a homebrew receiver.
>>
>> Thanks,
>> -Dan
>>
>> Wayne Vosberg wrote:
>>
>>> I hope someone is still working on this driver and will be able to
>>> point me in
>>> the right direction. I have a generic Phlips USB MCE remote:
>>>
>>> # lsusb -vvs 1:6
>>>
>>> Bus 001 Device 006: ID 0471:0815 Philips
>>> Device Descriptor:
>>> bLength 18
>>> bDescriptorType 1
>>> bcdUSB 1.10
>>> bDeviceClass 0 (Defined at Interface level)
>>> bDeviceSubClass 0
>>> bDeviceProtocol 0
>>> bMaxPacketSize0 16
>>> idVendor 0x0471 Philips
>>> idProduct 0x0815
>>> bcdDevice 0.00
>>> iManufacturer 1 Philips
>>> iProduct 2 eHome Infrared Transceiver
>>> iSerial 3 PH0018VA
>>> bNumConfigurations 1
>>> Configuration Descriptor:
>>> bLength 9
>>> bDescriptorType 2
>>> wTotalLength 32
>>> bNumInterfaces 1
>>> bConfigurationValue 1
>>> iConfiguration 0
>>> bmAttributes 0xa0
>>> Remote Wakeup
>>> MaxPower 100mA
>>> Interface Descriptor:
>>> bLength 9
>>> bDescriptorType 4
>>> bInterfaceNumber 0
>>> bAlternateSetting 0
>>> bNumEndpoints 2
>>> bInterfaceClass 255 Vendor Specific Class
>>> bInterfaceSubClass 255 Vendor Specific Subclass
>>> bInterfaceProtocol 255 Vendor Specific Protocol
>>> iInterface 0
>>> Endpoint Descriptor:
>>> bLength 7
>>> bDescriptorType 5
>>> bEndpointAddress 0x01 EP 1 OUT
>>> bmAttributes 2
>>> Transfer Type Bulk
>>> Synch Type none
>>> Usage Type Data
>>> wMaxPacketSize 0x0010 bytes 16 once
>>> bInterval 0
>>> Endpoint Descriptor:
>>> bLength 7
>>> bDescriptorType 5
>>> bEndpointAddress 0x81 EP 1 IN
>>> bmAttributes 2
>>> Transfer Type Bulk
>>> Synch Type none
>>> Usage Type Data
>>> wMaxPacketSize 0x0010 bytes 16 once
>>> bInterval 0
>>> Language IDs: (length=4)
>>> 0409 English(US)
>>>
>>> I modified the source to include my Vendor/Product IDs:
>>> /*
>>> #define USB_MCEUSB_VENDOR_ID 0x045e
>>> #define USB_MCEUSB_PRODUCT_ID 0x006d
>>> */
>>> #define USB_MCEUSB_VENDOR_ID 0x0471
>>> #define USB_MCEUSB_PRODUCT_ID 0x0815
>>>
>>> and everything compiles, starts and seems to run fine, except that
>>> neither irw nor irrecord ever see a button push.
>>>
>>> Here is the debug output from lirc_mceusb startup:
>>>
>>> lirc_dev: IR Remote Control driver registered, at major 61
>>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk
>>> out endpoint
>>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk
>>> in endpoint
>>> lirc_dev: lirc_register_plugin:sample_rate: 80
>>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res
>>> = 2 status = 0x1 0x0
>>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res
>>> = -32, devnum = 6
>>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
>>> data[0] = 0, data[1] = 0
>>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
>>> res = -32
>>> usbcore: registered new driver lirc_mceusb
>>>
>>> I suspect that -32 return from:
>>>
>>> res = usb_control_msg( udev, usb_rcvctrlpipe(udev, 0),
>>> 5, USB_TYPE_VENDOR, 0, 0,
>>> data, 2, HZ * 3 );
>>>
>>> is incorrect. Any idea on where to go from here?
>>>
>>> TIA
>>> Wayne Vosberg
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://productguide.itmanagersjournal.com/
>>>
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://productguide.itmanagersjournal.com/
>

Re: more lirc_mceusb

From: Wayne Vosberg <wayne.vosberg@gm...> - 2004-12-10 14:55

Dan,

Thanks for the update. Just to let you know -- these new remotes
*do* look different. Here is the MS one:

http://www.newegg.com/app/ViewProductDesc.asp?description=80-100-851&depa=0

and here is the generic:

http://www.newegg.com/app/ViewProductDesc.asp?description=80-100-202&depa=0

Note the big red Record button and the "Windows" button right in the center.

Is there anything I can do to help you update mceusb to support the
driver? Or will you even be the one working on it ...

thx,
Wayne

On Thu, 09 Dec 2004 22:02:02 -0800, Dan Conti <dconti@ac...> wrote:
> Hi,
>
> I haven't been monitoring this list for a bit, so i apologize for people
> who have had this problem and been confused. I have gotten a couple of
> off-list inquiries which i looked at for a bit.
>
> What is going on here is, unfortunately, MS and phillips have elected to
> change the remotes used for MCE 2005. It looks like this is just a
> change on the internals though, and the external housing and usb
> transceiver are the same.
>
> The result is that the protocol for the remotes is completely different;
> this is why the mceusb_setup lines are printing out bad result codes.
> The user experience isn't that good on this because, well, the driver
> isn't designed to have the wrong product and vendor id's thrown in there.
>
> If people who are having lirc_mceusb problems could verify that the
> remote you purchased looks exactly like this:
>
> http://www.pcalchemy.com/images/philips/philips-mce-remote.jpg
>
> That would be helpful. Naturally the bad news is that people looking to
> purchase these remotes may have no way of telling whether they are
> getting the older, microsoft version (which the driver supports) or the
> newer, phillips version (which it does not).
>
> For lirc, the solution will be to analyze the data the new usb
> transceiver expects and provides on the bus; it is possible that this is
> very similar, but not identical to the previous transceiver. If someone
> is interested in doing this, you are welcome to contact me regarding the
> original driver. It is also possible the protocol is completely
> different, and may warrant writing a new driver.
>
> For users who have this remote, the solution is to either a) wait for
> lirc to be updated to support the transceiver, or b) investigate
> building a homebrew receiver.
>
> Thanks,
> -Dan
>
>
>
> Wayne Vosberg wrote:
> > I hope someone is still working on this driver and will be able to point me in
> > the right direction. I have a generic Phlips USB MCE remote:
> >
> > # lsusb -vvs 1:6
> >
> > Bus 001 Device 006: ID 0471:0815 Philips
> > Device Descriptor:
> > bLength 18
> > bDescriptorType 1
> > bcdUSB 1.10
> > bDeviceClass 0 (Defined at Interface level)
> > bDeviceSubClass 0
> > bDeviceProtocol 0
> > bMaxPacketSize0 16
> > idVendor 0x0471 Philips
> > idProduct 0x0815
> > bcdDevice 0.00
> > iManufacturer 1 Philips
> > iProduct 2 eHome Infrared Transceiver
> > iSerial 3 PH0018VA
> > bNumConfigurations 1
> > Configuration Descriptor:
> > bLength 9
> > bDescriptorType 2
> > wTotalLength 32
> > bNumInterfaces 1
> > bConfigurationValue 1
> > iConfiguration 0
> > bmAttributes 0xa0
> > Remote Wakeup
> > MaxPower 100mA
> > Interface Descriptor:
> > bLength 9
> > bDescriptorType 4
> > bInterfaceNumber 0
> > bAlternateSetting 0
> > bNumEndpoints 2
> > bInterfaceClass 255 Vendor Specific Class
> > bInterfaceSubClass 255 Vendor Specific Subclass
> > bInterfaceProtocol 255 Vendor Specific Protocol
> > iInterface 0
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x01 EP 1 OUT
> > bmAttributes 2
> > Transfer Type Bulk
> > Synch Type none
> > Usage Type Data
> > wMaxPacketSize 0x0010 bytes 16 once
> > bInterval 0
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x81 EP 1 IN
> > bmAttributes 2
> > Transfer Type Bulk
> > Synch Type none
> > Usage Type Data
> > wMaxPacketSize 0x0010 bytes 16 once
> > bInterval 0
> > Language IDs: (length=4)
> > 0409 English(US)
> >
> > I modified the source to include my Vendor/Product IDs:
> > /*
> > #define USB_MCEUSB_VENDOR_ID 0x045e
> > #define USB_MCEUSB_PRODUCT_ID 0x006d
> > */
> > #define USB_MCEUSB_VENDOR_ID 0x0471
> > #define USB_MCEUSB_PRODUCT_ID 0x0815
> >
> > and everything compiles, starts and seems to run fine, except that
> > neither irw nor irrecord ever see a button push.
> >
> > Here is the debug output from lirc_mceusb startup:
> >
> > lirc_dev: IR Remote Control driver registered, at major 61
> > /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk out endpoint
> > /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk in endpoint
> > lirc_dev: lirc_register_plugin:sample_rate: 80
> > /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res
> > = 2 status = 0x1 0x0
> > /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res
> > = -32, devnum = 6
> > /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
> > data[0] = 0, data[1] = 0
> > /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res = -32
> > usbcore: registered new driver lirc_mceusb
> >
> > I suspect that -32 return from:
> >
> > res = usb_control_msg( udev, usb_rcvctrlpipe(udev, 0),
> > 5, USB_TYPE_VENDOR, 0, 0,
> > data, 2, HZ * 3 );
> >
> > is incorrect. Any idea on where to go from here?
> >
> > TIA
> > Wayne Vosberg
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://productguide.itmanagersjournal.com/
> >
>
>

Re: more lirc_mceusb

From: Trevor Kramer <tkramer@ha...> - 2004-12-10 18:03

So will this model work?

http://www.newegg.com/app/ViewProductDesc.asp?description=80-100
-851&depa=0

Trevor

On Dec 10, 2004, at 6:55 AM, Wayne Vosberg wrote:

> Dan,
>
> Thanks for the update. Just to let you know -- these new remotes
> *do* look different. Here is the MS one:
>
> http://www.newegg.com/app/ViewProductDesc.asp?description=80-100
> -851&depa=0
>
> and here is the generic:
>
> http://www.newegg.com/app/ViewProductDesc.asp?description=80-100
> -202&depa=0
>
> Note the big red Record button and the "Windows" button right in the
> center.
>
> Is there anything I can do to help you update mceusb to support the
> driver? Or will you even be the one working on it ...
>
> thx,
> Wayne
>
> On Thu, 09 Dec 2004 22:02:02 -0800, Dan Conti <dconti@ac...>
> wrote:
>> Hi,
>>
>> I haven't been monitoring this list for a bit, so i apologize for
>> people
>> who have had this problem and been confused. I have gotten a couple of
>> off-list inquiries which i looked at for a bit.
>>
>> What is going on here is, unfortunately, MS and phillips have elected
>> to
>> change the remotes used for MCE 2005. It looks like this is just a
>> change on the internals though, and the external housing and usb
>> transceiver are the same.
>>
>> The result is that the protocol for the remotes is completely
>> different;
>> this is why the mceusb_setup lines are printing out bad result
>> codes.
>> The user experience isn't that good on this because, well, the driver
>> isn't designed to have the wrong product and vendor id's thrown in
>> there.
>>
>> If people who are having lirc_mceusb problems could verify that the
>> remote you purchased looks exactly like this:
>>
>> http://www.pcalchemy.com/images/philips/philips-mce-remote.jpg
>>
>> That would be helpful. Naturally the bad news is that people looking
>> to
>> purchase these remotes may have no way of telling whether they are
>> getting the older, microsoft version (which the driver supports) or
>> the
>> newer, phillips version (which it does not).
>>
>> For lirc, the solution will be to analyze the data the new usb
>> transceiver expects and provides on the bus; it is possible that this
>> is
>> very similar, but not identical to the previous transceiver. If
>> someone
>> is interested in doing this, you are welcome to contact me regarding
>> the
>> original driver. It is also possible the protocol is completely
>> different, and may warrant writing a new driver.
>>
>> For users who have this remote, the solution is to either a) wait for
>> lirc to be updated to support the transceiver, or b) investigate
>> building a homebrew receiver.
>>
>> Thanks,
>> -Dan
>>
>>
>>
>> Wayne Vosberg wrote:
>>> I hope someone is still working on this driver and will be able to
>>> point me in
>>> the right direction. I have a generic Phlips USB MCE remote:
>>>
>>> # lsusb -vvs 1:6
>>>
>>> Bus 001 Device 006: ID 0471:0815 Philips
>>> Device Descriptor:
>>> bLength 18
>>> bDescriptorType 1
>>> bcdUSB 1.10
>>> bDeviceClass 0 (Defined at Interface level)
>>> bDeviceSubClass 0
>>> bDeviceProtocol 0
>>> bMaxPacketSize0 16
>>> idVendor 0x0471 Philips
>>> idProduct 0x0815
>>> bcdDevice 0.00
>>> iManufacturer 1 Philips
>>> iProduct 2 eHome Infrared Transceiver
>>> iSerial 3 PH0018VA
>>> bNumConfigurations 1
>>> Configuration Descriptor:
>>> bLength 9
>>> bDescriptorType 2
>>> wTotalLength 32
>>> bNumInterfaces 1
>>> bConfigurationValue 1
>>> iConfiguration 0
>>> bmAttributes 0xa0
>>> Remote Wakeup
>>> MaxPower 100mA
>>> Interface Descriptor:
>>> bLength 9
>>> bDescriptorType 4
>>> bInterfaceNumber 0
>>> bAlternateSetting 0
>>> bNumEndpoints 2
>>> bInterfaceClass 255 Vendor Specific Class
>>> bInterfaceSubClass 255 Vendor Specific Subclass
>>> bInterfaceProtocol 255 Vendor Specific Protocol
>>> iInterface 0
>>> Endpoint Descriptor:
>>> bLength 7
>>> bDescriptorType 5
>>> bEndpointAddress 0x01 EP 1 OUT
>>> bmAttributes 2
>>> Transfer Type Bulk
>>> Synch Type none
>>> Usage Type Data
>>> wMaxPacketSize 0x0010 bytes 16 once
>>> bInterval 0
>>> Endpoint Descriptor:
>>> bLength 7
>>> bDescriptorType 5
>>> bEndpointAddress 0x81 EP 1 IN
>>> bmAttributes 2
>>> Transfer Type Bulk
>>> Synch Type none
>>> Usage Type Data
>>> wMaxPacketSize 0x0010 bytes 16 once
>>> bInterval 0
>>> Language IDs: (length=4)
>>> 0409 English(US)
>>>
>>> I modified the source to include my Vendor/Product IDs:
>>> /*
>>> #define USB_MCEUSB_VENDOR_ID 0x045e
>>> #define USB_MCEUSB_PRODUCT_ID 0x006d
>>> */
>>> #define USB_MCEUSB_VENDOR_ID 0x0471
>>> #define USB_MCEUSB_PRODUCT_ID 0x0815
>>>
>>> and everything compiles, starts and seems to run fine, except that
>>> neither irw nor irrecord ever see a button push.
>>>
>>> Here is the debug output from lirc_mceusb startup:
>>>
>>> lirc_dev: IR Remote Control driver registered, at major 61
>>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk
>>> out endpoint
>>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk
>>> in endpoint
>>> lirc_dev: lirc_register_plugin:sample_rate: 80
>>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
>>> res
>>> = 2 status = 0x1 0x0
>>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
>>> res
>>> = -32, devnum = 6
>>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
>>> data[0] = 0, data[1] = 0
>>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
>>> res = -32
>>> usbcore: registered new driver lirc_mceusb
>>>
>>> I suspect that -32 return from:
>>>
>>> res = usb_control_msg( udev, usb_rcvctrlpipe(udev, 0),
>>> 5, USB_TYPE_VENDOR, 0, 0,
>>> data, 2, HZ * 3 );
>>>
>>> is incorrect. Any idea on where to go from here?
>>>
>>> TIA
>>> Wayne Vosberg
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real
>>> users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://productguide.itmanagersjournal.com/
>>>
>>
>>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
>

Re: more lirc_mceusb

From: Wayne Vosberg <wayne.vosberg@gm...> - 2004-12-10 18:59

I'm just *guessing* not, as this one has the same button layout as the
generic Philips (assuming of course the photos are correct). Look at
the jpg Dan sent earlier -- the button layout is a little different.

On Fri, 10 Dec 2004 10:03:10 -0800, Trevor Kramer <tkramer@ha...> wrote:
> So will this model work?
>
> http://www.newegg.com/app/ViewProductDesc.asp?description=80-100
> -851&depa=0
>
> Trevor
>
>
>
> On Dec 10, 2004, at 6:55 AM, Wayne Vosberg wrote:
>
> > Dan,
> >
> > Thanks for the update. Just to let you know -- these new remotes
> > *do* look different. Here is the MS one:
> >
> > http://www.newegg.com/app/ViewProductDesc.asp?description=80-100
> > -851&depa=0
> >
> > and here is the generic:
> >
> > http://www.newegg.com/app/ViewProductDesc.asp?description=80-100
> > -202&depa=0
> >
> > Note the big red Record button and the "Windows" button right in the
> > center.
> >
> > Is there anything I can do to help you update mceusb to support the
> > driver? Or will you even be the one working on it ...
> >
> > thx,
> > Wayne
> >
> > On Thu, 09 Dec 2004 22:02:02 -0800, Dan Conti <dconti@ac...>
> > wrote:
> >> Hi,
> >>
> >> I haven't been monitoring this list for a bit, so i apologize for
> >> people
> >> who have had this problem and been confused. I have gotten a couple of
> >> off-list inquiries which i looked at for a bit.
> >>
> >> What is going on here is, unfortunately, MS and phillips have elected
> >> to
> >> change the remotes used for MCE 2005. It looks like this is just a
> >> change on the internals though, and the external housing and usb
> >> transceiver are the same.
> >>
> >> The result is that the protocol for the remotes is completely
> >> different;
> >> this is why the mceusb_setup lines are printing out bad result
> >> codes.
> >> The user experience isn't that good on this because, well, the driver
> >> isn't designed to have the wrong product and vendor id's thrown in
> >> there.
> >>
> >> If people who are having lirc_mceusb problems could verify that the
> >> remote you purchased looks exactly like this:
> >>
> >> http://www.pcalchemy.com/images/philips/philips-mce-remote.jpg
> >>
> >> That would be helpful. Naturally the bad news is that people looking
> >> to
> >> purchase these remotes may have no way of telling whether they are
> >> getting the older, microsoft version (which the driver supports) or
> >> the
> >> newer, phillips version (which it does not).
> >>
> >> For lirc, the solution will be to analyze the data the new usb
> >> transceiver expects and provides on the bus; it is possible that this
> >> is
> >> very similar, but not identical to the previous transceiver. If
> >> someone
> >> is interested in doing this, you are welcome to contact me regarding
> >> the
> >> original driver. It is also possible the protocol is completely
> >> different, and may warrant writing a new driver.
> >>
> >> For users who have this remote, the solution is to either a) wait for
> >> lirc to be updated to support the transceiver, or b) investigate
> >> building a homebrew receiver.
> >>
> >> Thanks,
> >> -Dan
> >>
> >>
> >>
> >> Wayne Vosberg wrote:
> >>> I hope someone is still working on this driver and will be able to
> >>> point me in
> >>> the right direction. I have a generic Phlips USB MCE remote:
> >>>
> >>> # lsusb -vvs 1:6
> >>>
> >>> Bus 001 Device 006: ID 0471:0815 Philips
> >>> Device Descriptor:
> >>> bLength 18
> >>> bDescriptorType 1
> >>> bcdUSB 1.10
> >>> bDeviceClass 0 (Defined at Interface level)
> >>> bDeviceSubClass 0
> >>> bDeviceProtocol 0
> >>> bMaxPacketSize0 16
> >>> idVendor 0x0471 Philips
> >>> idProduct 0x0815
> >>> bcdDevice 0.00
> >>> iManufacturer 1 Philips
> >>> iProduct 2 eHome Infrared Transceiver
> >>> iSerial 3 PH0018VA
> >>> bNumConfigurations 1
> >>> Configuration Descriptor:
> >>> bLength 9
> >>> bDescriptorType 2
> >>> wTotalLength 32
> >>> bNumInterfaces 1
> >>> bConfigurationValue 1
> >>> iConfiguration 0
> >>> bmAttributes 0xa0
> >>> Remote Wakeup
> >>> MaxPower 100mA
> >>> Interface Descriptor:
> >>> bLength 9
> >>> bDescriptorType 4
> >>> bInterfaceNumber 0
> >>> bAlternateSetting 0
> >>> bNumEndpoints 2
> >>> bInterfaceClass 255 Vendor Specific Class
> >>> bInterfaceSubClass 255 Vendor Specific Subclass
> >>> bInterfaceProtocol 255 Vendor Specific Protocol
> >>> iInterface 0
> >>> Endpoint Descriptor:
> >>> bLength 7
> >>> bDescriptorType 5
> >>> bEndpointAddress 0x01 EP 1 OUT
> >>> bmAttributes 2
> >>> Transfer Type Bulk
> >>> Synch Type none
> >>> Usage Type Data
> >>> wMaxPacketSize 0x0010 bytes 16 once
> >>> bInterval 0
> >>> Endpoint Descriptor:
> >>> bLength 7
> >>> bDescriptorType 5
> >>> bEndpointAddress 0x81 EP 1 IN
> >>> bmAttributes 2
> >>> Transfer Type Bulk
> >>> Synch Type none
> >>> Usage Type Data
> >>> wMaxPacketSize 0x0010 bytes 16 once
> >>> bInterval 0
> >>> Language IDs: (length=4)
> >>> 0409 English(US)
> >>>
> >>> I modified the source to include my Vendor/Product IDs:
> >>> /*
> >>> #define USB_MCEUSB_VENDOR_ID 0x045e
> >>> #define USB_MCEUSB_PRODUCT_ID 0x006d
> >>> */
> >>> #define USB_MCEUSB_VENDOR_ID 0x0471
> >>> #define USB_MCEUSB_PRODUCT_ID 0x0815
> >>>
> >>> and everything compiles, starts and seems to run fine, except that
> >>> neither irw nor irrecord ever see a button push.
> >>>
> >>> Here is the debug output from lirc_mceusb startup:
> >>>
> >>> lirc_dev: IR Remote Control driver registered, at major 61
> >>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk
> >>> out endpoint
> >>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk
> >>> in endpoint
> >>> lirc_dev: lirc_register_plugin:sample_rate: 80
> >>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
> >>> res
> >>> = 2 status = 0x1 0x0
> >>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
> >>> res
> >>> = -32, devnum = 6
> >>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
> >>> data[0] = 0, data[1] = 0
> >>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
> >>> res = -32
> >>> usbcore: registered new driver lirc_mceusb
> >>>
> >>> I suspect that -32 return from:
> >>>
> >>> res = usb_control_msg( udev, usb_rcvctrlpipe(udev, 0),
> >>> 5, USB_TYPE_VENDOR, 0, 0,
> >>> data, 2, HZ * 3 );
> >>>
> >>> is incorrect. Any idea on where to go from here?
> >>>
> >>> TIA
> >>> Wayne Vosberg
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> SF email is sponsored by - The IT Product Guide
> >>> Read honest & candid reviews on hundreds of IT Products from real
> >>> users.
> >>> Discover which products truly live up to the hype. Start reading now.
> >>> http://productguide.itmanagersjournal.com/
> >>>
> >>
> >>
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real
> > users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://productguide.itmanagersjournal.com/
> >
>
>
> -------------------------------------------------------
>
>
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
>

Re: more lirc_mceusb

From: Jonathan Mills <jonmills@em...> - 2004-12-10 19:54

Here's the remote I bought:

http://www.newegg.com/app/ViewProductDesc.asp?description=80-100-202&depa=0

If someone will help get it working, I'll gladly give you as much info
about it as I can.

Quoting Trevor Kramer <tkramer@ha...>:

> So will this model work?
>
> http://www.newegg.com/app/ViewProductDesc.asp?description=80-100
> -851&depa=0
>
> Trevor
>
> On Dec 10, 2004, at 6:55 AM, Wayne Vosberg wrote:
>
> > Dan,
> >
> > Thanks for the update. Just to let you know -- these new remotes
> > *do* look different. Here is the MS one:
> >
> > http://www.newegg.com/app/ViewProductDesc.asp?description=80-100
> > -851&depa=0
> >
> > and here is the generic:
> >
> > http://www.newegg.com/app/ViewProductDesc.asp?description=80-100
> > -202&depa=0
> >
> > Note the big red Record button and the "Windows" button right in
> the
> > center.
> >
> > Is there anything I can do to help you update mceusb to support
> the
> > driver? Or will you even be the one working on it ...
> >
> > thx,
> > Wayne
> >
> > On Thu, 09 Dec 2004 22:02:02 -0800, Dan Conti <dconti@ac...>
>
> > wrote:
> >> Hi,
> >>
> >> I haven't been monitoring this list for a bit, so i apologize for
>
> >> people
> >> who have had this problem and been confused. I have gotten a
> couple of
> >> off-list inquiries which i looked at for a bit.
> >>
> >> What is going on here is, unfortunately, MS and phillips have
> elected
> >> to
> >> change the remotes used for MCE 2005. It looks like this is just
> a
> >> change on the internals though, and the external housing and usb
> >> transceiver are the same.
> >>
> >> The result is that the protocol for the remotes is completely
> >> different;
> >> this is why the mceusb_setup lines are printing out bad result
>
> >> codes.
> >> The user experience isn't that good on this because, well, the
> driver
> >> isn't designed to have the wrong product and vendor id's thrown in
>
> >> there.
> >>
> >> If people who are having lirc_mceusb problems could verify that
> the
> >> remote you purchased looks exactly like this:
> >>
> >> http://www.pcalchemy.com/images/philips/philips-mce-remote.jpg
> >>
> >> That would be helpful. Naturally the bad news is that people
> looking
> >> to
> >> purchase these remotes may have no way of telling whether they
> are
> >> getting the older, microsoft version (which the driver supports)
> or
> >> the
> >> newer, phillips version (which it does not).
> >>
> >> For lirc, the solution will be to analyze the data the new usb
> >> transceiver expects and provides on the bus; it is possible that
> this
> >> is
> >> very similar, but not identical to the previous transceiver. If
> >> someone
> >> is interested in doing this, you are welcome to contact me
> regarding
> >> the
> >> original driver. It is also possible the protocol is completely
> >> different, and may warrant writing a new driver.
> >>
> >> For users who have this remote, the solution is to either a) wait
> for
> >> lirc to be updated to support the transceiver, or b) investigate
> >> building a homebrew receiver.
> >>
> >> Thanks,
> >> -Dan
> >>
> >>
> >>
> >> Wayne Vosberg wrote:
> >>> I hope someone is still working on this driver and will be able
> to
> >>> point me in
> >>> the right direction. I have a generic Phlips USB MCE remote:
> >>>
> >>> # lsusb -vvs 1:6
> >>>
> >>> Bus 001 Device 006: ID 0471:0815 Philips
> >>> Device Descriptor:
> >>> bLength 18
> >>> bDescriptorType 1
> >>> bcdUSB 1.10
> >>> bDeviceClass 0 (Defined at Interface level)
> >>> bDeviceSubClass 0
> >>> bDeviceProtocol 0
> >>> bMaxPacketSize0 16
> >>> idVendor 0x0471 Philips
> >>> idProduct 0x0815
> >>> bcdDevice 0.00
> >>> iManufacturer 1 Philips
> >>> iProduct 2 eHome Infrared Transceiver
> >>> iSerial 3 PH0018VA
> >>> bNumConfigurations 1
> >>> Configuration Descriptor:
> >>> bLength 9
> >>> bDescriptorType 2
> >>> wTotalLength 32
> >>> bNumInterfaces 1
> >>> bConfigurationValue 1
> >>> iConfiguration 0
> >>> bmAttributes 0xa0
> >>> Remote Wakeup
> >>> MaxPower 100mA
> >>> Interface Descriptor:
> >>> bLength 9
> >>> bDescriptorType 4
> >>> bInterfaceNumber 0
> >>> bAlternateSetting 0
> >>> bNumEndpoints 2
> >>> bInterfaceClass 255 Vendor Specific Class
> >>> bInterfaceSubClass 255 Vendor Specific Subclass
> >>> bInterfaceProtocol 255 Vendor Specific Protocol
> >>> iInterface 0
> >>> Endpoint Descriptor:
> >>> bLength 7
> >>> bDescriptorType 5
> >>> bEndpointAddress 0x01 EP 1 OUT
> >>> bmAttributes 2
> >>> Transfer Type Bulk
> >>> Synch Type none
> >>> Usage Type Data
> >>> wMaxPacketSize 0x0010 bytes 16 once
> >>> bInterval 0
> >>> Endpoint Descriptor:
> >>> bLength 7
> >>> bDescriptorType 5
> >>> bEndpointAddress 0x81 EP 1 IN
> >>> bmAttributes 2
> >>> Transfer Type Bulk
> >>> Synch Type none
> >>> Usage Type Data
> >>> wMaxPacketSize 0x0010 bytes 16 once
> >>> bInterval 0
> >>> Language IDs: (length=4)
> >>> 0409 English(US)
> >>>
> >>> I modified the source to include my Vendor/Product IDs:
> >>> /*
> >>> #define USB_MCEUSB_VENDOR_ID 0x045e
> >>> #define USB_MCEUSB_PRODUCT_ID 0x006d
> >>> */
> >>> #define USB_MCEUSB_VENDOR_ID 0x0471
> >>> #define USB_MCEUSB_PRODUCT_ID 0x0815
> >>>
> >>> and everything compiles, starts and seems to run fine, except
> that
> >>> neither irw nor irrecord ever see a button push.
> >>>
> >>> Here is the debug output from lirc_mceusb startup:
> >>>
> >>> lirc_dev: IR Remote Control driver registered, at major 61
> >>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a
> bulk
> >>> out endpoint
> >>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a
> bulk
> >>> in endpoint
> >>> lirc_dev: lirc_register_plugin:sample_rate: 80
> >>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup
> -
> >>> res
> >>> = 2 status = 0x1 0x0
> >>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup
> -
> >>> res
> >>> = -32, devnum = 6
> >>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup
> -
> >>> data[0] = 0, data[1] = 0
> >>> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup
> -
> >>> res = -32
> >>> usbcore: registered new driver lirc_mceusb
> >>>
> >>> I suspect that -32 return from:
> >>>
> >>> res = usb_control_msg( udev, usb_rcvctrlpipe(udev, 0),
> >>> 5, USB_TYPE_VENDOR, 0, 0,
> >>> data, 2, HZ * 3 );
> >>>
> >>> is incorrect. Any idea on where to go from here?
> >>>
> >>> TIA
> >>> Wayne Vosberg
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> SF email is sponsored by - The IT Product Guide
> >>> Read honest & candid reviews on hundreds of IT Products from real
>
> >>> users.
> >>> Discover which products truly live up to the hype. Start reading
> now.
> >>> http://productguide.itmanagersjournal.com/
> >>>
> >>
> >>
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real
>
> > users.
> > Discover which products truly live up to the hype. Start reading
> now.
> > http://productguide.itmanagersjournal.com/
> >
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users.
> Discover which products truly live up to the hype. Start reading now.
>
> http://productguide.itmanagersjournal.com/
>

Re: more lirc_mceusb

From: EC <zybhjk@ve...> - 2004-12-11 01:54

I too just ordered my mceusb remote which is the new unsupported
version. I was even looking at the older (slightly cheaper) one, but
decided there wouldnt be any bad differences between the two :-/. I do
not know enough to write a driver for it, however I would be happy to
help with any testing or info you may need.

Will newegg allow me to return this for the other version?

//ec

Thu, 09 Dec 2004 22:02:02 -0800 | Dan Conti <dconti@ac...>

::-Hi,
::-
::-I haven't been monitoring this list for a bit, so i apologize for
people
::-who have had this problem and been confused. I have gotten a couple
of ::-off-list inquiries which i looked at for a bit.
::-
::-What is going on here is, unfortunately, MS and phillips have elected
to ::-change the remotes used for MCE 2005. It looks like this is just a
::-change on the internals though, and the external housing and usb
::-transceiver are the same.
::-
::-The result is that the protocol for the remotes is completely
different; ::- this is why the mceusb_setup lines are printing out bad
result codes. ::-The user experience isn't that good on this because,
well, the driver ::-isn't designed to have the wrong product and vendor
id's thrown in there.::-
::-If people who are having lirc_mceusb problems could verify that the
::-remote you purchased looks exactly like this:
::-
::-http://www.pcalchemy.com/images/philips/philips-mce-remote.jpg
::-
::-That would be helpful. Naturally the bad news is that people looking
to ::-purchase these remotes may have no way of telling whether they are
::-getting the older, microsoft version (which the driver supports) or
the ::-newer, phillips version (which it does not).
::-
::-For lirc, the solution will be to analyze the data the new usb
::-transceiver expects and provides on the bus; it is possible that this
is ::-very similar, but not identical to the previous transceiver. If
someone ::-is interested in doing this, you are welcome to contact me
regarding the ::-original driver. It is also possible the protocol is
completely ::-different, and may warrant writing a new driver.
::-
::-For users who have this remote, the solution is to either a) wait for
::-lirc to be updated to support the transceiver, or b) investigate
::-building a homebrew receiver.
::-
::-Thanks,
::--Dan
::-
::-Wayne Vosberg wrote:
::-> I hope someone is still working on this driver and will be able to
point me in::-> the right direction. I have a generic Phlips USB MCE
remote:::->
::-> # lsusb -vvs 1:6
::->
::-> Bus 001 Device 006: ID 0471:0815 Philips
::-> Device Descriptor:
::-> bLength 18
::-> bDescriptorType 1
::-> bcdUSB 1.10
::-> bDeviceClass 0 (Defined at Interface level)
::-> bDeviceSubClass 0
::-> bDeviceProtocol 0
::-> bMaxPacketSize0 16
::-> idVendor 0x0471 Philips
::-> idProduct 0x0815
::-> bcdDevice 0.00
::-> iManufacturer 1 Philips
::-> iProduct 2 eHome Infrared Transceiver
::-> iSerial 3 PH0018VA
::-> bNumConfigurations 1
::-> Configuration Descriptor:
::-> bLength 9
::-> bDescriptorType 2
::-> wTotalLength 32
::-> bNumInterfaces 1
::-> bConfigurationValue 1
::-> iConfiguration 0
::-> bmAttributes 0xa0
::-> Remote Wakeup
::-> MaxPower 100mA
::-> Interface Descriptor:
::-> bLength 9
::-> bDescriptorType 4
::-> bInterfaceNumber 0
::-> bAlternateSetting 0
::-> bNumEndpoints 2
::-> bInterfaceClass 255 Vendor Specific Class
::-> bInterfaceSubClass 255 Vendor Specific Subclass
::-> bInterfaceProtocol 255 Vendor Specific Protocol
::-> iInterface 0
::-> Endpoint Descriptor:
::-> bLength 7
::-> bDescriptorType 5
::-> bEndpointAddress 0x01 EP 1 OUT
::-> bmAttributes 2
::-> Transfer Type Bulk
::-> Synch Type none
::-> Usage Type Data
::-> wMaxPacketSize 0x0010 bytes 16 once
::-> bInterval 0
::-> Endpoint Descriptor:
::-> bLength 7
::-> bDescriptorType 5
::-> bEndpointAddress 0x81 EP 1 IN
::-> bmAttributes 2
::-> Transfer Type Bulk
::-> Synch Type none
::-> Usage Type Data
::-> wMaxPacketSize 0x0010 bytes 16 once
::-> bInterval 0
::-> Language IDs: (length=4)
::-> 0409 English(US)
::->
::-> I modified the source to include my Vendor/Product IDs:
::-> /*
::-> #define USB_MCEUSB_VENDOR_ID 0x045e
::-> #define USB_MCEUSB_PRODUCT_ID 0x006d
::-> */
::-> #define USB_MCEUSB_VENDOR_ID 0x0471
::-> #define USB_MCEUSB_PRODUCT_ID 0x0815
::->
::-> and everything compiles, starts and seems to run fine, except that
::-> neither irw nor irrecord ever see a button push.
::->
::-> Here is the debug output from lirc_mceusb startup:
::->
::-> lirc_dev: IR Remote Control driver registered, at major 61
::-> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk
out endpoint::-> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we
found a bulk in endpoint::-> lirc_dev: lirc_register_plugin:sample_rate:
80::-> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup
- res::-> = 2 status = 0x1 0x0
::-> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
res::-> = -32, devnum = 6
::-> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
::-> data[0] = 0, data[1] = 0
::-> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
res = -32::-> usbcore: registered new driver lirc_mceusb
::->
::-> I suspect that -32 return from:
::->
::-> res = usb_control_msg( udev, usb_rcvctrlpipe(udev, 0),
::-> 5, USB_TYPE_VENDOR, 0, 0,
::-> data, 2, HZ * 3 );
::->
::-> is incorrect. Any idea on where to go from here?
::->
::-> TIA
::-> Wayne Vosberg
::->
::->
::-> -------------------------------------------------------
::-> SF email is sponsored by - The IT Product Guide
::-> Read honest & candid reviews on hundreds of IT Products from real
users.::-> Discover which products truly live up to the hype. Start
reading now. ::-> http://productguide.itmanagersjournal.com/
::->
::-
::-
::-
::--------------------------------------------------------
::-SF email is sponsored by - The IT Product Guide
::-Read honest & candid reviews on hundreds of IT Products from real
users.::-Discover which products truly live up to the hype. Start
reading now. ::-http://productguide.itmanagersjournal.com/

Re: more lirc_mceusb

From: Dan Conti <dconti@ac...> - 2004-12-11 04:34

To clarify, i do not believe the MCE remotes offered by newegg will work
with the current driver. I believe both of the models newegg currently
offers are based on the new (philips) hardware, and are just different
labeling.

EC wrote:
> I too just ordered my mceusb remote which is the new unsupported
> version. I was even looking at the older (slightly cheaper) one, but
> decided there wouldnt be any bad differences between the two :-/. I do
> not know enough to write a driver for it, however I would be happy to
> help with any testing or info you may need.
>
> Will newegg allow me to return this for the other version?
>
> //ec
>
> Thu, 09 Dec 2004 22:02:02 -0800 | Dan Conti <dconti@ac...>
>
> ::-Hi,
> ::-
> ::-I haven't been monitoring this list for a bit, so i apologize for
> people
> ::-who have had this problem and been confused. I have gotten a couple
> of ::-off-list inquiries which i looked at for a bit.
> ::-
> ::-What is going on here is, unfortunately, MS and phillips have elected
> to ::-change the remotes used for MCE 2005. It looks like this is just a
> ::-change on the internals though, and the external housing and usb
> ::-transceiver are the same.
> ::-
> ::-The result is that the protocol for the remotes is completely
> different; ::- this is why the mceusb_setup lines are printing out bad
> result codes. ::-The user experience isn't that good on this because,
> well, the driver ::-isn't designed to have the wrong product and vendor
> id's thrown in there.::-
> ::-If people who are having lirc_mceusb problems could verify that the
> ::-remote you purchased looks exactly like this:
> ::-
> ::-http://www.pcalchemy.com/images/philips/philips-mce-remote.jpg
> ::-
> ::-That would be helpful. Naturally the bad news is that people looking
> to ::-purchase these remotes may have no way of telling whether they are
> ::-getting the older, microsoft version (which the driver supports) or
> the ::-newer, phillips version (which it does not).
> ::-
> ::-For lirc, the solution will be to analyze the data the new usb
> ::-transceiver expects and provides on the bus; it is possible that this
> is ::-very similar, but not identical to the previous transceiver. If
> someone ::-is interested in doing this, you are welcome to contact me
> regarding the ::-original driver. It is also possible the protocol is
> completely ::-different, and may warrant writing a new driver.
> ::-
> ::-For users who have this remote, the solution is to either a) wait for
> ::-lirc to be updated to support the transceiver, or b) investigate
> ::-building a homebrew receiver.
> ::-
> ::-Thanks,
> ::--Dan
> ::-
> ::-Wayne Vosberg wrote:
> ::-> I hope someone is still working on this driver and will be able to
> point me in::-> the right direction. I have a generic Phlips USB MCE
> remote:::->
> ::-> # lsusb -vvs 1:6
> ::->
> ::-> Bus 001 Device 006: ID 0471:0815 Philips
> ::-> Device Descriptor:
> ::-> bLength 18
> ::-> bDescriptorType 1
> ::-> bcdUSB 1.10
> ::-> bDeviceClass 0 (Defined at Interface level)
> ::-> bDeviceSubClass 0
> ::-> bDeviceProtocol 0
> ::-> bMaxPacketSize0 16
> ::-> idVendor 0x0471 Philips
> ::-> idProduct 0x0815
> ::-> bcdDevice 0.00
> ::-> iManufacturer 1 Philips
> ::-> iProduct 2 eHome Infrared Transceiver
> ::-> iSerial 3 PH0018VA
> ::-> bNumConfigurations 1
> ::-> Configuration Descriptor:
> ::-> bLength 9
> ::-> bDescriptorType 2
> ::-> wTotalLength 32
> ::-> bNumInterfaces 1
> ::-> bConfigurationValue 1
> ::-> iConfiguration 0
> ::-> bmAttributes 0xa0
> ::-> Remote Wakeup
> ::-> MaxPower 100mA
> ::-> Interface Descriptor:
> ::-> bLength 9
> ::-> bDescriptorType 4
> ::-> bInterfaceNumber 0
> ::-> bAlternateSetting 0
> ::-> bNumEndpoints 2
> ::-> bInterfaceClass 255 Vendor Specific Class
> ::-> bInterfaceSubClass 255 Vendor Specific Subclass
> ::-> bInterfaceProtocol 255 Vendor Specific Protocol
> ::-> iInterface 0
> ::-> Endpoint Descriptor:
> ::-> bLength 7
> ::-> bDescriptorType 5
> ::-> bEndpointAddress 0x01 EP 1 OUT
> ::-> bmAttributes 2
> ::-> Transfer Type Bulk
> ::-> Synch Type none
> ::-> Usage Type Data
> ::-> wMaxPacketSize 0x0010 bytes 16 once
> ::-> bInterval 0
> ::-> Endpoint Descriptor:
> ::-> bLength 7
> ::-> bDescriptorType 5
> ::-> bEndpointAddress 0x81 EP 1 IN
> ::-> bmAttributes 2
> ::-> Transfer Type Bulk
> ::-> Synch Type none
> ::-> Usage Type Data
> ::-> wMaxPacketSize 0x0010 bytes 16 once
> ::-> bInterval 0
> ::-> Language IDs: (length=4)
> ::-> 0409 English(US)
> ::->
> ::-> I modified the source to include my Vendor/Product IDs:
> ::-> /*
> ::-> #define USB_MCEUSB_VENDOR_ID 0x045e
> ::-> #define USB_MCEUSB_PRODUCT_ID 0x006d
> ::-> */
> ::-> #define USB_MCEUSB_VENDOR_ID 0x0471
> ::-> #define USB_MCEUSB_PRODUCT_ID 0x0815
> ::->
> ::-> and everything compiles, starts and seems to run fine, except that
> ::-> neither irw nor irrecord ever see a button push.
> ::->
> ::-> Here is the debug output from lirc_mceusb startup:
> ::->
> ::-> lirc_dev: IR Remote Control driver registered, at major 61
> ::-> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk
> out endpoint::-> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we
> found a bulk in endpoint::-> lirc_dev: lirc_register_plugin:sample_rate:
> 80::-> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup
> - res::-> = 2 status = 0x1 0x0
> ::-> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
> res::-> = -32, devnum = 6
> ::-> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
> ::-> data[0] = 0, data[1] = 0
> ::-> /root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
> res = -32::-> usbcore: registered new driver lirc_mceusb
> ::->
> ::-> I suspect that -32 return from:
> ::->
> ::-> res = usb_control_msg( udev, usb_rcvctrlpipe(udev, 0),
> ::-> 5, USB_TYPE_VENDOR, 0, 0,
> ::-> data, 2, HZ * 3 );
> ::->
> ::-> is incorrect. Any idea on where to go from here?
> ::->
> ::-> TIA
> ::-> Wayne Vosberg
> ::->
> ::->
> ::-> -------------------------------------------------------
> ::-> SF email is sponsored by - The IT Product Guide
> ::-> Read honest & candid reviews on hundreds of IT Products from real
> users.::-> Discover which products truly live up to the hype. Start
> reading now. ::-> http://productguide.itmanagersjournal.com/
> ::->
> ::-
> ::-
> ::-
> ::--------------------------------------------------------
> ::-SF email is sponsored by - The IT Product Guide
> ::-Read honest & candid reviews on hundreds of IT Products from real
> users.::-Discover which products truly live up to the hype. Start
> reading now. ::-http://productguide.itmanagersjournal.com/
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
>

Re: more lirc_mceusb

From: Dan Conti <dconti@ac...> - 2004-12-11 04:38

This will probably not be me. I haven't had a media PC set up in a year
and a half, and haven't used my remote since then. If someone else is
interested in what is required to get this working, i can probably give
pointers based on the original driver experience.

Thanks

Wayne Vosberg wrote:
> Dan,
>
> Thanks for the update. Just to let you know -- these new remotes
> *do* look different. Here is the MS one:
>
> http://www.newegg.com/app/ViewProductDesc.asp?description=80-100-851&depa=0
>
> and here is the generic:
>
> http://www.newegg.com/app/ViewProductDesc.asp?description=80-100-202&depa=0
>
> Note the big red Record button and the "Windows" button right in the center.
>
> Is there anything I can do to help you update mceusb to support the
> driver? Or will you even be the one working on it ...
>
> thx,
> Wayne
>
> On Thu, 09 Dec 2004 22:02:02 -0800, Dan Conti <dconti@ac...> wrote:
>
>>Hi,
>>
>>I haven't been monitoring this list for a bit, so i apologize for people
>>who have had this problem and been confused. I have gotten a couple of
>>off-list inquiries which i looked at for a bit.
>>
>>What is going on here is, unfortunately, MS and phillips have elected to
>>change the remotes used for MCE 2005. It looks like this is just a
>>change on the internals though, and the external housing and usb
>>transceiver are the same.
>>
>>The result is that the protocol for the remotes is completely different;
>> this is why the mceusb_setup lines are printing out bad result codes.
>>The user experience isn't that good on this because, well, the driver
>>isn't designed to have the wrong product and vendor id's thrown in there.
>>
>>If people who are having lirc_mceusb problems could verify that the
>>remote you purchased looks exactly like this:
>>
>>http://www.pcalchemy.com/images/philips/philips-mce-remote.jpg
>>
>>That would be helpful. Naturally the bad news is that people looking to
>>purchase these remotes may have no way of telling whether they are
>>getting the older, microsoft version (which the driver supports) or the
>>newer, phillips version (which it does not).
>>
>>For lirc, the solution will be to analyze the data the new usb
>>transceiver expects and provides on the bus; it is possible that this is
>>very similar, but not identical to the previous transceiver. If someone
>>is interested in doing this, you are welcome to contact me regarding the
>>original driver. It is also possible the protocol is completely
>>different, and may warrant writing a new driver.
>>
>>For users who have this remote, the solution is to either a) wait for
>>lirc to be updated to support the transceiver, or b) investigate
>>building a homebrew receiver.
>>
>>Thanks,
>>-Dan
>>
>>
>>
>>Wayne Vosberg wrote:
>>
>>>I hope someone is still working on this driver and will be able to point me in
>>>the right direction. I have a generic Phlips USB MCE remote:
>>>
>>># lsusb -vvs 1:6
>>>
>>>Bus 001 Device 006: ID 0471:0815 Philips
>>>Device Descriptor:
>>> bLength 18
>>> bDescriptorType 1
>>> bcdUSB 1.10
>>> bDeviceClass 0 (Defined at Interface level)
>>> bDeviceSubClass 0
>>> bDeviceProtocol 0
>>> bMaxPacketSize0 16
>>> idVendor 0x0471 Philips
>>> idProduct 0x0815
>>> bcdDevice 0.00
>>> iManufacturer 1 Philips
>>> iProduct 2 eHome Infrared Transceiver
>>> iSerial 3 PH0018VA
>>> bNumConfigurations 1
>>> Configuration Descriptor:
>>> bLength 9
>>> bDescriptorType 2
>>> wTotalLength 32
>>> bNumInterfaces 1
>>> bConfigurationValue 1
>>> iConfiguration 0
>>> bmAttributes 0xa0
>>> Remote Wakeup
>>> MaxPower 100mA
>>> Interface Descriptor:
>>> bLength 9
>>> bDescriptorType 4
>>> bInterfaceNumber 0
>>> bAlternateSetting 0
>>> bNumEndpoints 2
>>> bInterfaceClass 255 Vendor Specific Class
>>> bInterfaceSubClass 255 Vendor Specific Subclass
>>> bInterfaceProtocol 255 Vendor Specific Protocol
>>> iInterface 0
>>> Endpoint Descriptor:
>>> bLength 7
>>> bDescriptorType 5
>>> bEndpointAddress 0x01 EP 1 OUT
>>> bmAttributes 2
>>> Transfer Type Bulk
>>> Synch Type none
>>> Usage Type Data
>>> wMaxPacketSize 0x0010 bytes 16 once
>>> bInterval 0
>>> Endpoint Descriptor:
>>> bLength 7
>>> bDescriptorType 5
>>> bEndpointAddress 0x81 EP 1 IN
>>> bmAttributes 2
>>> Transfer Type Bulk
>>> Synch Type none
>>> Usage Type Data
>>> wMaxPacketSize 0x0010 bytes 16 once
>>> bInterval 0
>>> Language IDs: (length=4)
>>> 0409 English(US)
>>>
>>>I modified the source to include my Vendor/Product IDs:
>>>/*
>>>#define USB_MCEUSB_VENDOR_ID 0x045e
>>>#define USB_MCEUSB_PRODUCT_ID 0x006d
>>>*/
>>>#define USB_MCEUSB_VENDOR_ID 0x0471
>>>#define USB_MCEUSB_PRODUCT_ID 0x0815
>>>
>>>and everything compiles, starts and seems to run fine, except that
>>>neither irw nor irrecord ever see a button push.
>>>
>>>Here is the debug output from lirc_mceusb startup:
>>>
>>>lirc_dev: IR Remote Control driver registered, at major 61
>>>/root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk out endpoint
>>>/root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: we found a bulk in endpoint
>>>lirc_dev: lirc_register_plugin:sample_rate: 80
>>>/root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res
>>>= 2 status = 0x1 0x0
>>>/root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res
>>>= -32, devnum = 6
>>>/root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup -
>>>data[0] = 0, data[1] = 0
>>>/root/lirc-0.7.0/drivers/lirc_mceusb/lirc_mceusb.c: mceusb_setup - res = -32
>>>usbcore: registered new driver lirc_mceusb
>>>
>>>I suspect that -32 return from:
>>>
>>> res = usb_control_msg( udev, usb_rcvctrlpipe(udev, 0),
>>> 5, USB_TYPE_VENDOR, 0, 0,
>>> data, 2, HZ * 3 );
>>>
>>>is incorrect. Any idea on where to go from here?
>>>
>>>TIA
>>>Wayne Vosberg
>>>
>>>
>>>-------------------------------------------------------
>>>SF email is sponsored by - The IT Product Guide
>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>Discover which products truly live up to the hype. Start reading now.
>>>http://productguide.itmanagersjournal.com/
>>>
>>
>>
>

Linux Infrared Remote Control

Email Archive: lirc-list (read-only)

Thread View

About SourceForge

Find Software

Develop Software

Community

Help