I'll explain my conclusions here so it may help someone else, somedays...
You were right, 0x11 is part of the XON/XOFF control bytes.
This is set by default through the termios structures (c_iflag) and is transparent to
the stack since the io takes care of everything.
It's possible to turn it off by using tcsetattr() (on a client point of view).
Since I didn't want to touch the code of the Axis stack, I had to do
it "reverse" from the
device point of view, using:
tty->termios->c_iflag = tty->termios->c_iflag & ~IXON & ~IXOFF
It works now perfect, my "virtual device" is talking to your stack and they understand each others !
Peter Kjellerstedt wrote:
> -----Original Message-----
> From: Gordon McNutt [mailto:firstname.lastname@example.org]
> Sent: 07 May 2001 17:06
> To: email@example.com
> Cc: firstname.lastname@example.org
> Subject: Re: [bluetooth-dev] Problem writing a TTY under the stack.
> Laurent Eschenauer wrote:
> > Hello everyone,
> > I have a really strange problem while working with the stack, I hope
> > that you may help...
> > I'm trying to develop a driver that I have to put UNDER the stack.
> > This is the first step on the
> > long journey to build a virtual bleutooth driver that may
> be used with
> > any tty based stack out
> > there...
> > That means that I'm writing a tty like driver which acts like
> > /dev/ttySx and I connect the Axis stack to this driver.
> > It works almost fine in USER_MODE but I didn't implement yet to
> > support the kernel mode, it is quite tricky
> > to support the IOCTL to register the bt stack discipline.
> If you have
> > any suggestion on how to do that, I would
> > thank you a lot but it's not my problem for tonight !
> > Here is the problem. When my driver has to send a message
> to the stack
> > I use something like this:
> > tty->ldisc.receive_buf(tty, (u8 *) data, NULL, len)
> > If you don't understand this line, you probably can't help me. I'm
> > calling the receive
> > function of the line discipline above me to send the buffer.
> The line discipline is N_BT, right? Where does your driver
> get the data
> from before passing it up to the ldisc? Does your driver see the 0x11
> byte before passing the buffer up?
0x11 is ^Q, so a guess would be that it is ^S/^Q flow control
somewhere that is stealing the byte. There should be problems
with 0x13 (^S) then too.
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to email@example.com