"Alessio Massaro" <[EMAIL PROTECTED]> writes:
> Just a quick recap for the people from the Linux-IrDA mailing list:
> it's just that some LIRC users are dreaming to use LIRC with IrDA h/w.
> Some do read FAQs, some do not and then complain :-)
Well, I have done some thinking about this issue, and I must say that I'm
not really sure about how to solve this the "best" way.
You are talking about being "normal" serial ports, but that is something at
least I have choosen IrDA not to be. I have implemented all the device
drivers as network device drivers, so things are a bit different (more
frame oriented). The device drivers deliver IrDA frames and currently
nothing else.
But I don't think that we must have a tty interface to the IrDA device
drivers in order to support more "RAW" reads and writes. And btw. forget
about IrCOMM, it has nothing to do with this issue.
I have actually already implemented support for "raw" reads and writes for
the device drivers, since some of the dongles require this. It would be
easy to make an ioctl to the device drivers to tell them that they should
switch to a different infrared mode and deliver raw data instead. But then
they cannot deliver IrDA frames, so we must "tag" the information as
something else. Well, it could be delivered as IrDA frames (since the whole
architecture is already in place), but then we must "tag" it somewhere in
the skb struct, so that IrLAP does not try to decode it (anyway, this is
not a problem)
So in fact you can do all reads and writes using the socket packet
interface from user-space after setting the device driver to the correct
mode (easy!). My irdaping program does this and sends/receives frames
directly to the device driver. What you need to implmement is just the
ioctl stuff to make the device drivers change personality (most chips
support other modes), and support for these other modes in the device
drivers. I don't know if these other modes are frame oriented or not, but
the user-space application should probably just treat the input as a byte
stream (SOCK_STREAM should be the right choice then), and figure out what
all this data means. So I think it should be relatively easy to make this
work, but somebody other than me would have to put in the effort, since I
have my mind on so many other things right now.
If you don't want to deliver frames to user-space since you already have
some kernel code you want to use, then you should implement support for a
new frame type and make the device drivers receive_{ask,hpsir,irda-c,
tv-rem, etc} deliver the frames to somewhere else:
/*
- * Feed it to IrLAP layer
+ * Feed it to the LIRC layer
*/
skb->dev = &idev->netdev;
skb->mac.raw = skb->data;
- skb->protocol = htons(ETH_P_IRDA);
+ skb->protocol = htons(ETH_P_LIRC); /* or some other name */
netif_rx(skb);
Then the LIRC handler will receive all such "raw" frames. Registering a new
packet type is easy:
lirc_packet_type.type = htons(ETH_P_LIRC);
dev_add_pack(&lirc_packet_type);
So you must decide which approach to use:
1. Use the packet interface and have all the LIRC stuff in user-space.
2. Impl. a new packet handler (see above)
3. Make a tty interface for the device drivers (I will however never accept
such changes to "my" device drivers, but you can always implement your
own).
Does this make any sense?
-- Dag
--
/ Dag Brattli | The Linux-IrDA Project /
// University of Tromsoe, Norway | Infrared communication for Linux //
/// http://www.cs.uit.no/~dagb | http://www.cs.uit.no/linux-irda/ ///
