Dear all,
we just had some discussion on the behaviour of the RFCOMM TTY driver with
some BlueZ users. The problem is that it is not realy possible to have
RFCOMM server ports when using the TTY driver (/dev/rfcommX).
The suggested behaviour would be that a /dev/rfcommX device always exists
(like any normal tty device), no matter if a bluetooth connection to the
DLC exists or not. This would than much more act like a normal TTY. If
there is a Bluetooth connection the cable is plugged, if there is no
Bluetooth connection the cable is unplugged.
After looking at the source of the RFC tty driver it should be possible to
make it work like this by a few changes:
Add a flag to the driver struct to make it a "server" port.
Change the tty open behaviour.
Modify the tty write / ioctl functions to honour the actual connection
status (just do nothing / throw write data away if not connected).
Question: is there anything I missed which would provide from doing a
described ??
Is there any good other reason why the tty driver should act like it
currently does ??
Any input welcome.
Thank you and best regards,
Peter
| Peter Wippich Voice: +49 30 46776411 |
| G&W Instruments GmbH fax: +49 30 46776419 |
| Gustav-Meyer-Allee 25, Geb. 12 Email: [email protected] |
| D-13355 Berlin / Germany |
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
> the main API of RFCOMM is the socket. So I don't actually bother that
> much with the TTY stuff. However patches are always welcome. Feel free
> to provide actual code for the change you described.
Yes, I know that BlueZ is focused on the socket API. This isn't bad as
long as you can use sockets. In the case we have here the tty API is
needed because of backward compatibility reasons.
I will try to implement the suggested changes and send a patch if it
works. And I hope I don't forget to change my editor to Hard Tab indenting
so it gets a chance to get accepted.
Ciao,
Peter
| Peter Wippich Voice: +49 30 46776411 |
| G&W Instruments GmbH fax: +49 30 46776419 |
| Gustav-Meyer-Allee 25, Geb. 12 Email: [email protected] |
| D-13355 Berlin / Germany |
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Peter,
> we just had some discussion on the behaviour of the RFCOMM TTY driver with
> some BlueZ users. The problem is that it is not realy possible to have
> RFCOMM server ports when using the TTY driver (/dev/rfcommX).
>
> The suggested behaviour would be that a /dev/rfcommX device always exists
> (like any normal tty device), no matter if a bluetooth connection to the
> DLC exists or not. This would than much more act like a normal TTY. If
> there is a Bluetooth connection the cable is plugged, if there is no
> Bluetooth connection the cable is unplugged.
>
> After looking at the source of the RFC tty driver it should be possible to
> make it work like this by a few changes:
> Add a flag to the driver struct to make it a "server" port.
> Change the tty open behaviour.
> Modify the tty write / ioctl functions to honour the actual connection
> status (just do nothing / throw write data away if not connected).
>
> Question: is there anything I missed which would provide from doing a
> described ??
> Is there any good other reason why the tty driver should act like it
> currently does ??
the main API of RFCOMM is the socket. So I don't actually bother that
much with the TTY stuff. However patches are always welcome. Feel free
to provide actual code for the change you described.
Regards
Marcel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel