[CC's shortened]
On Tue, 13 Nov 2001, Jean Tourrilhes wrote: > I don't know anything about RAW IR. People were talking of > that on the list, see the archive. I guess Dag would be the most > likely to implement that. As the driver interface is standard and > quite simple, having a serial wrapper around it would allow to export > all IrDA drivers as RAW IR in one go (instead of having to do them one > by one). This seems to point in a direction similar to what I'm just asking in the other thread. My guess is RAW IR would be just the byte stream of serial traffic - without any asynch. wrapping and independent from an irda stack. With all the media-access and link management issues left to whoever is using this. So having a tty interface representing this sounds pretty reasonable to me. OTOH I'm not sure, whether this would make much sense for non-SIR modes. IMHO most (if not all) of the controllers implement these modes based on some notion of data packages. So the point is how should a tty-like implementation know, when to close the current package and start a new one? The semantics of a serial bytestream has no such thing. Well, you could use some fixed packet size - but then the tty-user would have to take care to always send integer multiples of this or there will some bytes remain somewhere waiting to become a packet... And sending fixed length=1 packets wouldn't be an option, I assume ;-) My feeling is this RAW IR thing (as a serial tty-like bytestream) makes sense for SIR only, when the controller operates in a fifo mode. For MIR or [V]FIR modes I think a PF_PACKET, SOCK_RAW socket representation would be more appropriate. In fact you can already use it this way right now - the "only" problem is to disconnect the IrDA stack so it wouldn't see and complain about what's going on down there. Yes, I know, we have this ir-serial implementation for the USB dongles. I really don't see what the advantage is to make this a tty interface. According to the specs the dongle does only operate with _packets_ (meant, but not enforced to contain IrLAP payload) and handles the whole wrapping, as a mandatory requirement. Agreed, simple "cat foo-bar > /dev/ir-serial" is not possible with a network device, but I don't see the point which would make much difference for socket/sendto/recvfrom compared to open/write/read in real-world applications? Anyway, as I've said in the other thread, I'm also thinking a common implementation of an interface to get access to representation(s) of data from IR drivers independent from an irda stack might be something useful. Martin _______________________________________________ Linux-IrDA mailing list - [EMAIL PROTECTED] http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
