-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hallo,
after searching the mailing list and searching the web, I still don't
know how to access correctly the serial port (in user space known as
/dev/ttyS01)
This thread ends before the answer was given and the site redirecting
too is restructured: http://marc.info/?l=kernelnewbies&m=98314502419089&w=2
would somebody be so kind to give me an example:
with this behaviour:
1. read from port
2. output via printk()
3. write to port
I'm learning how to write modules:
I've created already my own char-dev and used it in user-space.
However I don't know really how to get information from kernel-code to
solve this.
thx in advance
14.05.2007 14:46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGSF2FAAomYJ1taN8RAnPfAKCdpnT+Uxa8a1Mc85TCyDzNwsvuQQCgzHIx
f7V/XEWtWCa2IWtYjk7W7dg=
=y/NM
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lars K.W. Gohlke schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hallo,
>
> after searching the mailing list and searching the web, I still don't
> know how to access correctly the serial port (in user space known as
> /dev/ttyS01)
>
> This thread ends before the answer was given and the site redirecting
> too is restructured: http://marc.info/?l=kernelnewbies&m=98314502419089&w=2
>
> would somebody be so kind to give me an example:
>
> with this behaviour:
>
> 1. read from port
> 2. output via printk()
> 3. write to port
>
> I'm learning how to write modules:
>
> I've created already my own char-dev and used it in user-space.
> However I don't know really how to get information from kernel-code to
> solve this.
>
> thx in advance
>
> 14.05.2007 14:46
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
>
> iD8DBQFGSF2FAAomYJ1taN8RAnPfAKCdpnT+Uxa8a1Mc85TCyDzNwsvuQQCgzHIx
> f7V/XEWtWCa2IWtYjk7W7dg=
> =y/NM
> -----END PGP SIGNATURE-----
would be somebody so polite and give me at least a hint?
Where to search concretely, or small template.
thx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGSJ7yAAomYJ1taN8RAmVqAJ9Fwr9eqAlYK5rSBj1efs0gBDgMuACgmEuZ
u0EvSiC5ORBLFnIGp0tdpNE=
=pdLz
-----END PGP SIGNATURE-----
On May 14 2007 19:40, Lars K.W. Gohlke wrote:
>>
>> hallo,
>>
>> after searching the mailing list and searching the web, I still don't
>> know how to access correctly the serial port (in user space known as
>> /dev/ttyS01)
http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad
>> This thread ends before the answer was given and the site redirecting
>> too is restructured:
>> http://marc.info/?l=kernelnewbies&m=98314502419089&w=2
>>
>> would somebody be so kind to give me an example:
>>
>> with this behaviour:
>>
>> 1. read from port
>> 2. output via printk()
>> 3. write to port
inb/inw/inl, printk, outb/outw/outl.
>> I've created already my own char-dev and used it in user-space.
>> However I don't know really how to get information from kernel-code to
>> solve this.
http://lwn.net/Kernel/LDD3/
> would be somebody so polite and give me at least a hint?
> Where to search concretely, or small template.
It's been 4 hours and 40 minutes, and you already expect an answer?
I don't remember you having paid anyone...
Jan
--
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jan Engelhardt schrieb:
> On May 14 2007 19:40, Lars K.W. Gohlke wrote:
>>> hallo,
>>>
>>> after searching the mailing list and searching the web, I still don't
>>> know how to access correctly the serial port (in user space known as
>>> /dev/ttyS01)
>
> http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad
>
>>> This thread ends before the answer was given and the site redirecting
>>> too is restructured:
>>> http://marc.info/?l=kernelnewbies&m=98314502419089&w=2
>>>
>>> would somebody be so kind to give me an example:
>>>
>>> with this behaviour:
>>>
>>> 1. read from port
>>> 2. output via printk()
>>> 3. write to port
>
> inb/inw/inl, printk, outb/outw/outl.
>
>>> I've created already my own char-dev and used it in user-space.
>>> However I don't know really how to get information from kernel-code to
>>> solve this.
>
> http://lwn.net/Kernel/LDD3/
>
>> would be somebody so polite and give me at least a hint?
>> Where to search concretely, or small template.
>
> It's been 4 hours and 40 minutes, and you already expect an answer?
> I don't remember you having paid anyone...
>
>
> Jan
sorry, for my impatience, but I saw the traffic on the list and was
wondering ... .
Nevermind, thx.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGSMW4AAomYJ1taN8RAjgYAKDAspdXlQhsFCaGMkr5Y0NiBH5k/ACeN9Gc
xHGfKF0NaSyuA6hlm5byp0o=
=wUWl
-----END PGP SIGNATURE-----
Am 14.05.2007 15:00 schrieb Lars K.W. Gohlke:
> after searching the mailing list and searching the web, I still don't
> know how to access correctly the serial port (in user space known as
> /dev/ttyS01)
I can only tell you how I did it in the special case of the
ser_gigaset driver which drives an ISDN device attached to
a serial port: I implemented it as a line discipline which
is associated to the appropriate serial port by a userspace
daemon.
Reading material:
Documentation/tty.txt
documentation on the line discipline interface
include/linux/tty.h
include/linux/tty_ldisc.h
definitions for same
drivers/isdn/gigaset/ser-gigaset.c
my code - a simple example of abusing the line
discipline interface for your own ends :-)
> would somebody be so kind to give me an example:
I hope the following will help you some. If not, feel free to
ask again.
> with this behaviour:
>
> 1. read from port
That's not how things work in the kernel. There is no system
call for reading some data that has arrived on that port or
blocking if there is none, like a userspace program would do.
Instead, when you register your line discipline you provide
a callback function (receive_buf) for the serial driver to
call when data has been received. That function can be called
at any time and has to deal with the data as it gets it.
> 2. output via printk()
You can of course put a printk() in your receive_buf function.
But ultimately you'll want to do more than that with the data,
I'm sure.
> 3. write to port
That's easy. :-) No, it isn't. The serial driver *does*
provide a function (aptly called "write") for sending data
to the serial port, but you can't just call it any time you
like. You have to synchronize with the driver by waiting for
it to call your "write_wakeup" callback before you can call
its write function again.
HTH
T.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
Am 14.05.2007 22:00 schrieb Jan Engelhardt:
> On May 14 2007 19:40, Lars K.W. Gohlke wrote:
>>>
>>> after searching the mailing list and searching the web, I still don't
>>> know how to access correctly the serial port (in user space known as
>>> /dev/ttyS01)
>
> http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad
That's not nice, sending a newbie on a wild goose chase like that.
He doesn't want to write to a file from kernel after all. Reading
FAQs is never bad, of course, but reading that particular one
won't help him at all with this questions.
Lars: Read that at your leisure if you have time. It is quite
educating, though completely irrelevant to your questions.
>>> would somebody be so kind to give me an example:
>>>
>>> with this behaviour:
>>>
>>> 1. read from port
>>> 2. output via printk()
>>> 3. write to port
>
> inb/inw/inl, printk, outb/outw/outl.
This is even less nice. You're sending him down the road of
directly programming UART registers, knowing full well (I hope)
that this a Bad Thing. What will you tell him when he comes back
covered in bruises?
Lars: Ignore this advice. You don't want to use in[bwl]/out[bwl]
to directly access serial port hardware for which the kernel has
a working driver already. That way lies pain, as I know from
experience. Read up on the line discipline interface instead, as
described in my previous reply.
HTH
T.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
On May 15 2007 01:00, Tilman Schmidt wrote:
>Am 14.05.2007 22:00 schrieb Jan Engelhardt:
>> On May 14 2007 19:40, Lars K.W. Gohlke wrote:
>>>>
>>>> after searching the mailing list and searching the web, I still don't
>>>> know how to access correctly the serial port (in user space known as
>>>> /dev/ttyS01)
>>
>> http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad
>
>That's not nice, sending a newbie on a wild goose chase like that.
>He doesn't want to write to a file from kernel after all. Reading
>FAQs is never bad, of course, but reading that particular one
>won't help him at all with this questions.
The original poster is quite unclear about how he wants to access the
serial port. Given that he uses "in user space known as", I deducted
he means kernel space. Then of course is the big question since there
are a number of ways:
- access by filp
- access by ldisc
- access by <whatever drives console=ttyS0> (printk and something)
- access by inb (perhaps it is a serial port with a custom chip
that the OP wanted to write a driver for?)
Unfortunately, my magic sphere is out of order, so I could only take
a really really vague guess at what was wanted.
>Lars: Read that at your leisure if you have time. It is quite
>educating, though completely irrelevant to your questions.
>
>>>> would somebody be so kind to give me an example:
>>>>
>>>> with this behaviour:
>>>>
>>>> 1. read from port
>>>> 2. output via printk()
>>>> 3. write to port
>>
>> inb/inw/inl, printk, outb/outw/outl.
>
>This is even less nice. You're sending him down the road of
>directly programming UART registers, knowing full well (I hope)
>that this a Bad Thing.
This is how 8250.c works.
Jan
--
Am 17.05.2007 08:15 schrieb huang ying:
> I think the "serio" (through drivers/input/serio/serport.c) may be a
> choice too, like that in linux/drivers/input/mouse/sermouse.c, which
> is an example to program serial port in kernel space.
Interesting. I wonder if that would have been a better choice for
the Gigaset M101 driver. It seems even to have a probe mechanism
so one could try to determine if the expected device is really
connected to the port.
Is there any documentation on this interface? I find the source a
bit hard to understand, sparsely commented as it is.
Thanks
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Am 15.05.2007 10:43 schrieb Jan Engelhardt:
> On May 15 2007 01:00, Tilman Schmidt wrote:
>> Am 14.05.2007 22:00 schrieb Jan Engelhardt:
>>> On May 14 2007 19:40, Lars K.W. Gohlke wrote:
>>>>> after searching the mailing list and searching the web, I still don't
>>>>> know how to access correctly the serial port (in user space known as
>>>>> /dev/ttyS01)
>>> http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad
>> That's not nice, sending a newbie on a wild goose chase like that.
>> He doesn't want to write to a file from kernel after all. Reading
>> FAQs is never bad, of course, but reading that particular one
>> won't help him at all with this questions.
>
> The original poster is quite unclear about how he wants to access the
> serial port. [...]
> Unfortunately, my magic sphere is out of order, so I could only take
> a really really vague guess at what was wanted.
He asked about "the correct way". The document you cited will just
warn him against one of the many incorrect ones. That's less helpful
than not answering at all.
>>> inb/inw/inl, printk, outb/outw/outl.
>> This is even less nice. You're sending him down the road of
>> directly programming UART registers, knowing full well (I hope)
>> that this a Bad Thing.
>
> This is how 8250.c works.
Exactly. Which is one reason why other parts of the kernel should not
do it themselves. (Another being of course that if you do it that way,
your code will only work with that particular type of serial port
hardware. As the last of the Ten Commandments for C Programmers has
been declaring for ages, you shouldn't assume that "All the world's a
VAX^WPC.")
HTH
T.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tilman Schmidt schrieb:
> Am 15.05.2007 10:43 schrieb Jan Engelhardt:
>> On May 15 2007 01:00, Tilman Schmidt wrote:
>>> Am 14.05.2007 22:00 schrieb Jan Engelhardt:
>>>> On May 14 2007 19:40, Lars K.W. Gohlke wrote:
>>>>>> after searching the mailing list and searching the web, I still don't
>>>>>> know how to access correctly the serial port (in user space known as
>>>>>> /dev/ttyS01)
>>>> http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad
>>> That's not nice, sending a newbie on a wild goose chase like that.
>>> He doesn't want to write to a file from kernel after all. Reading
>>> FAQs is never bad, of course, but reading that particular one
>>> won't help him at all with this questions.
>> The original poster is quite unclear about how he wants to access the
>> serial port. [...]
>> Unfortunately, my magic sphere is out of order, so I could only take
>> a really really vague guess at what was wanted.
>
> He asked about "the correct way". The document you cited will just
> warn him against one of the many incorrect ones. That's less helpful
> than not answering at all.
>
>>>> inb/inw/inl, printk, outb/outw/outl.
>>> This is even less nice. You're sending him down the road of
>>> directly programming UART registers, knowing full well (I hope)
>>> that this a Bad Thing.
>> This is how 8250.c works.
>
> Exactly. Which is one reason why other parts of the kernel should not
> do it themselves. (Another being of course that if you do it that way,
> your code will only work with that particular type of serial port
> hardware. As the last of the Ten Commandments for C Programmers has
> been declaring for ages, you shouldn't assume that "All the world's a
> VAX^WPC.")
>
> HTH
> T.
>
ok, I have read everything and also have read the chapters about
tty_drivers. However I'm not really understand, how to ... .
I will summarize the concrete scenario, which will lead to the
understanding and further solution of deadling with serial driver.
[scenario]
1. in userspace I'm doing: > date > /dev/ttyS0
2. in kernelspace I want to print out this date.
[/scenario]
I'm really new to kernel coding, that's why I maybe understand some
functions not the proper way.
I'm a bit confused.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGVWeCAAomYJ1taN8RAjaAAJ476KjYne485RBVnwA3/h+FMFz+HgCgkE6w
FK4mahSRx8L4+Lo/hNKQWks=
=Cozv
-----END PGP SIGNATURE-----
On May 24 2007 12:22, Lars K.W. Gohlke wrote:
>
> ok, I have read everything and also have read the chapters about
> tty_drivers. However I'm not really understand, how to ... .
>
> I will summarize the concrete scenario, which will lead to the
> understanding and further solution of deadling with serial driver.
>
> [scenario]
>
> 1. in userspace I'm doing: > date > /dev/ttyS0
> 2. in kernelspace I want to print out this date.
>
> [/scenario]
>
> I'm really new to kernel coding, that's why I maybe understand some
> functions not the proper way.
>
> I'm a bit confused.
So am I. Usually, you connect two different machines with a serial cable.
(Leaving out the special case of connecting ttyS0-ttyS1 on the same machine.)
This poses the first question: whose kernelspace? the sender or
the receiver side? And by "this date" do you perhaps mean
"whatever was sent", or specifically a date? And print to _where_?
Up to now, it looks like you want to do "cat </dev/ttyS0" in-kernel.
Jan
--
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jan Engelhardt schrieb:
> On May 24 2007 12:22, Lars K.W. Gohlke wrote:
>> ok, I have read everything and also have read the chapters about
>> tty_drivers. However I'm not really understand, how to ... .
>>
>> I will summarize the concrete scenario, which will lead to the
>> understanding and further solution of deadling with serial driver.
>>
>> [scenario]
>>
>> 1. in userspace I'm doing: > date > /dev/ttyS0
>> 2. in kernelspace I want to print out this date.
>>
>> [/scenario]
>>
>> I'm really new to kernel coding, that's why I maybe understand some
>> functions not the proper way.
>>
>> I'm a bit confused.
>
> So am I. Usually, you connect two different machines with a serial cable.
> (Leaving out the special case of connecting ttyS0-ttyS1 on the same machine.)
>
> This poses the first question: whose kernelspace? the sender or
> the receiver side? And by "this date" do you perhaps mean
> "whatever was sent", or specifically a date? And print to _where_?
>
> Up to now, it looks like you want to do "cat </dev/ttyS0" in-kernel.
>
>
> Jan
date is an example
and you got it, I want to do "cat </dev/ttyS0" in-kernel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGVWy0AAomYJ1taN8RAu7/AJ9+1irJURFy5KFy/wzHqSXXD5sRgACfSi49
ec5AnOQoTz2nCt//siaiTNs=
=uj4G
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tilman Schmidt schrieb:
> Am 14.05.2007 15:00 schrieb Lars K.W. Gohlke:
>> after searching the mailing list and searching the web, I still don't
>> know how to access correctly the serial port (in user space known as
>> /dev/ttyS01)
>
> I can only tell you how I did it in the special case of the
> ser_gigaset driver which drives an ISDN device attached to
> a serial port: I implemented it as a line discipline which
> is associated to the appropriate serial port by a userspace
> daemon.
>
> Reading material:
>
> Documentation/tty.txt
> documentation on the line discipline interface
> include/linux/tty.h
> include/linux/tty_ldisc.h
> definitions for same
> drivers/isdn/gigaset/ser-gigaset.c
> my code - a simple example of abusing the line
> discipline interface for your own ends :-)
>
>> would somebody be so kind to give me an example:
>
> I hope the following will help you some. If not, feel free to
> ask again.
>
>> with this behaviour:
>>
>> 1. read from port
>
> That's not how things work in the kernel. There is no system
> call for reading some data that has arrived on that port or
> blocking if there is none, like a userspace program would do.
> Instead, when you register your line discipline you provide
> a callback function (receive_buf) for the serial driver to
> call when data has been received. That function can be called
> at any time and has to deal with the data as it gets it.
>
>> 2. output via printk()
>
> You can of course put a printk() in your receive_buf function.
> But ultimately you'll want to do more than that with the data,
> I'm sure.
>
>> 3. write to port
>
> That's easy. :-) No, it isn't. The serial driver *does*
> provide a function (aptly called "write") for sending data
> to the serial port, but you can't just call it any time you
> like. You have to synchronize with the driver by waiting for
> it to call your "write_wakeup" callback before you can call
> its write function again.
>
> HTH
> T.
>
I read you piece of code but it is overkill for me, I dont not see the
wood for the trees.
Many lines I'm recognizing as things I have read about kernel in my
book, but far away from understanding.
Anyway thx.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGVW47AAomYJ1taN8RAuccAJ9TIvocrrVFCwcxnFsZZo8cLxLgKACglwD3
/zudmDgwvWo/5St0zC0UnHI=
=1Qgs
-----END PGP SIGNATURE-----
On May 24 2007 12:45, Lars K.W. Gohlke wrote:
>Date: Thu, 24 May 2007 12:45:06 +0200
>From: Lars K.W. Gohlke <[email protected]>
>To: Jan Engelhardt <[email protected]>
>Cc: Tilman Schmidt <[email protected]>, [email protected]
>Subject: Re: How to access correctly serial port inside module?
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jan Engelhardt schrieb:
>> On May 24 2007 12:22, Lars K.W. Gohlke wrote:
>> > ok, I have read everything and also have read the chapters about
>> > tty_drivers. However I'm not really understand, how to ... .
>> >
>> > I will summarize the concrete scenario, which will lead to the
>> > understanding and further solution of deadling with serial driver.
>> >
>> > [scenario]
>> >
>> > 1. in userspace I'm doing: > date > /dev/ttyS0
>> > 2. in kernelspace I want to print out this date.
>> >
>> > [/scenario]
>> >
>> > I'm really new to kernel coding, that's why I maybe understand some
>> > functions not the proper way.
>> >
>> > I'm a bit confused.
>>
>> So am I. Usually, you connect two different machines with a serial cable.
>> (Leaving out the special case of connecting ttyS0-ttyS1 on the same
>> machine.)
>>
>> This poses the first question: whose kernelspace? the sender or
>> the receiver side? And by "this date" do you perhaps mean
>> "whatever was sent", or specifically a date? And print to _where_?
>>
>> Up to now, it looks like you want to do "cat </dev/ttyS0" in-kernel.
>>
>>
>> Jan
>
> date is an example
>
> and you got it, I want to do "cat </dev/ttyS0" in-kernel.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
>
> iD8DBQFGVWy0AAomYJ1taN8RAu7/AJ9+1irJURFy5KFy/wzHqSXXD5sRgACfSi49
> ec5AnOQoTz2nCt//siaiTNs=
> =uj4G
> -----END PGP SIGNATURE-----
>
Jan
--
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jan Engelhardt schrieb:
> On May 24 2007 12:45, Lars K.W. Gohlke wrote:
>
>> Date: Thu, 24 May 2007 12:45:06 +0200
>> From: Lars K.W. Gohlke <[email protected]>
>> To: Jan Engelhardt <[email protected]>
>> Cc: Tilman Schmidt <[email protected]>, [email protected]
>> Subject: Re: How to access correctly serial port inside module?
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Jan Engelhardt schrieb:
>>> On May 24 2007 12:22, Lars K.W. Gohlke wrote:
>>>> ok, I have read everything and also have read the chapters about
>>>> tty_drivers. However I'm not really understand, how to ... .
>>>>
>>>> I will summarize the concrete scenario, which will lead to the
>>>> understanding and further solution of deadling with serial driver.
>>>>
>>>> [scenario]
>>>>
>>>> 1. in userspace I'm doing: > date > /dev/ttyS0
>>>> 2. in kernelspace I want to print out this date.
>>>>
>>>> [/scenario]
>>>>
>>>> I'm really new to kernel coding, that's why I maybe understand some
>>>> functions not the proper way.
>>>>
>>>> I'm a bit confused.
>>> So am I. Usually, you connect two different machines with a serial cable.
>>> (Leaving out the special case of connecting ttyS0-ttyS1 on the same
>>> machine.)
>>>
>>> This poses the first question: whose kernelspace? the sender or
>>> the receiver side? And by "this date" do you perhaps mean
>>> "whatever was sent", or specifically a date? And print to _where_?
>>>
>>> Up to now, it looks like you want to do "cat </dev/ttyS0" in-kernel.
>>>
>>>
>>> Jan
>> date is an example
>>
>> and you got it, I want to do "cat </dev/ttyS0" in-kernel.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
>>
>> iD8DBQFGVWy0AAomYJ1taN8RAu7/AJ9+1irJURFy5KFy/wzHqSXXD5sRgACfSi49
>> ec5AnOQoTz2nCt//siaiTNs=
>> =uj4G
>> -----END PGP SIGNATURE-----
>>
>
> Jan
for example I want to print out it with printk().
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGVXUBAAomYJ1taN8RAix3AJ0Q8GTuMg2eJsFbD/fdQFN8SnmoqgCgrHDO
gTj9ygAshefP33OY7a3MGyk=
=Mt6g
-----END PGP SIGNATURE-----
Am 24.05.2007 12:22 schrieb Lars K.W. Gohlke:
> I will summarize the concrete scenario, which will lead to the
> understanding and further solution of deadling with serial driver.
>
> [scenario]
>
> 1. in userspace I'm doing: > date > /dev/ttyS0
> 2. in kernelspace I want to print out this date.
>
> [/scenario]
I must admit that now I do not understand anything anymore.
I thought you wanted to receive some data over an RS232 serial
port and process it in your kernel module, but this doesn't
look like that at all.
So what is it you are trying to do?
Do you just want to write something to a file in userspace and
receive it in your kernel module?
Does that userspace file have to be called /dev/ttyS0?
(If so, why?)
Or do you want an actual serial port hardware to be involved?
(If so, how?)
Regards,
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tilman Schmidt schrieb:
> Am 24.05.2007 12:22 schrieb Lars K.W. Gohlke:
>> I will summarize the concrete scenario, which will lead to the
>> understanding and further solution of deadling with serial driver.
>>
>> [scenario]
>>
>> 1. in userspace I'm doing: > date > /dev/ttyS0
>> 2. in kernelspace I want to print out this date.
>>
>> [/scenario]
>
> I must admit that now I do not understand anything anymore.
> I thought you wanted to receive some data over an RS232 serial
> port and process it in your kernel module, but this doesn't
> look like that at all.
>
> So what is it you are trying to do?
> Do you just want to write something to a file in userspace and
> receive it in your kernel module?
I want to read from serial port (I mean the port, which is called
/dev/ttyS0 in user-space). Then I want copy_to_user() it through
/proc/serialPort
This is just to get familiar with driver programming (in kernelspace),
it could be better done in userspace - I know. But this is for learning.
It is a kind of synthetic problem, but after this, I hope too know how
to handle further ones.
Understood? It is a little bit strange, but hope it is explained well. ;)
If tell me that for /dev/ttyS0 I can adept it to /dev/ttyS1 etc..
thx
>
> Regards,
> Tilman
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGVck/AAomYJ1taN8RAiYwAJ96kYK6byxHea5MhvO0zaEB1yAXQQCdGS9c
PFU39kx+d/xgj9QxusfEplc=
=OeRZ
-----END PGP SIGNATURE-----
On May 24 2007 19:19, Lars K.W. Gohlke wrote:
> I want to read from serial port (I mean the port, which is called
> /dev/ttyS0 in user-space). Then I want copy_to_user() it through
> /proc/serialPort
>
> This is just to get familiar with driver programming (in kernelspace),
> it could be better done in userspace - I know. But this is for learning.
>
> It is a kind of synthetic problem, but after this, I hope too know how
> to handle further ones.
>
> Understood? It is a little bit strange, but hope it is explained well. ;)
>
> If tell me that for /dev/ttyS0 I can adept it to /dev/ttyS1 etc..
struct file *filp = filp_open("/dev/ttyS0");
char buf[4096];
mm_segment_t oldfs = get_fs();
loff_t pos = 0;
set_ds(KERNEL_DS);
while (vfs_read(filp, buf, sizeof(buf), &pos) > 0)
printk("%s\n", buf);
filp_close(filp);
[I've warned about it... ;-) ]
Jan
--
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jan Engelhardt schrieb:
> On May 24 2007 19:19, Lars K.W. Gohlke wrote:
>> I want to read from serial port (I mean the port, which is called
>> /dev/ttyS0 in user-space). Then I want copy_to_user() it through
>> /proc/serialPort
>>
>> This is just to get familiar with driver programming (in kernelspace),
>> it could be better done in userspace - I know. But this is for learning.
>>
>> It is a kind of synthetic problem, but after this, I hope too know how
>> to handle further ones.
>>
>> Understood? It is a little bit strange, but hope it is explained well. ;)
>>
>> If tell me that for /dev/ttyS0 I can adept it to /dev/ttyS1 etc..
>
>
> struct file *filp = filp_open("/dev/ttyS0");
> char buf[4096];
> mm_segment_t oldfs = get_fs();
> loff_t pos = 0;
>
> set_ds(KERNEL_DS);
> while (vfs_read(filp, buf, sizeof(buf), &pos) > 0)
> printk("%s\n", buf);
>
> filp_close(filp);
>
>
>
> [I've warned about it... ;-) ]
>
> Jan
is it the way to access from kernelspace the userspace fs?
the not-correct-way?
If it is so, I will wait for another solution ;)
Dont want to learn writing nasty kernel code. *g*
Anyway thx.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGVeRlAAomYJ1taN8RAj4LAJ4oD+3yGy6k69nBEXi5BSda+tdeNACeOCTY
+nJSUcsGpwh25uDjyC2GKRU=
=twVz
-----END PGP SIGNATURE-----
Am 24.05.2007 21:15 schrieb Lars K.W. Gohlke:
> Jan Engelhardt schrieb:
[code proposal]
>> [I've warned about it... ;-) ]
>
> is it the way to access from kernelspace the userspace fs?
> the not-correct-way?
Yes, indeed.
> If it is so, I will wait for another solution ;)
I'm not sure waiting will help. The roasted pigeons will not come
flying into your mouth.
The possible solutions have been sketched out for you:
a) open the device file from the kernel (described by Jan):
actively discouraged by the kernelnewbies.org FAQ document,
and probably won't even work IMHO
b) program the serial port directly (described by Jan):
will work only with one type of hardware and you'll have to
disable the regular serial driver first; frowned upon by kernel
gurus as "reinventing the wheel"
c) abuse the line discipline interface (described by me):
moderately well documented, and there's precedent for using it
that way in the well-accepted PPP module as well as my humble
contribution, the ser_gigaset driver; requires a userspace
daemon for pushing the line discipline module on the serial
port and keeping it there
d) use the serio interface (described by Ying Huang):
potentially cleaner conceptually and seems to work without a
userspace daemon, but apparently not documented anywhere
except in the source files drivers/input/serio/serport.c
and linux/drivers/input/mouse/sermouse.c
Now it's your turn to decide.
HTH
T.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
On May 28 2007 19:05, Tilman Schmidt wrote:
>Am 24.05.2007 21:15 schrieb Lars K.W. Gohlke:
>> Jan Engelhardt schrieb:
>[code proposal]
>>> [I've warned about it... ;-) ]
>>
>> is it the way to access from kernelspace the userspace fs?
>> the not-correct-way?
>
>Yes, indeed.
>
>> If it is so, I will wait for another solution ;)
>
>I'm not sure waiting will help. The roasted pigeons will not come
>flying into your mouth.
>
>The possible solutions have been sketched out for you:
>
>a) open the device file from the kernel (described by Jan):
> actively discouraged by the kernelnewbies.org FAQ document,
> and probably won't even work IMHO
It does work. "It just needs work." :)
See https://dev.computergmbh.de/svn/quad_dsp/trunk/ for an example.
Jan
--
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tilman Schmidt schrieb:
> Am 24.05.2007 21:15 schrieb Lars K.W. Gohlke:
>> Jan Engelhardt schrieb:
> [code proposal]
>>> [I've warned about it... ;-) ]
>> is it the way to access from kernelspace the userspace fs?
>> the not-correct-way?
>
> Yes, indeed.
>
>> If it is so, I will wait for another solution ;)
>
> I'm not sure waiting will help. The roasted pigeons will not come
> flying into your mouth.
>
> The possible solutions have been sketched out for you:
>
> a) open the device file from the kernel (described by Jan):
> actively discouraged by the kernelnewbies.org FAQ document,
> and probably won't even work IMHO
>
> b) program the serial port directly (described by Jan):
> will work only with one type of hardware and you'll have to
> disable the regular serial driver first; frowned upon by kernel
> gurus as "reinventing the wheel"
>
> c) abuse the line discipline interface (described by me):
> moderately well documented, and there's precedent for using it
> that way in the well-accepted PPP module as well as my humble
> contribution, the ser_gigaset driver; requires a userspace
> daemon for pushing the line discipline module on the serial
> port and keeping it there
>
> d) use the serio interface (described by Ying Huang):
> potentially cleaner conceptually and seems to work without a
> userspace daemon, but apparently not documented anywhere
> except in the source files drivers/input/serio/serport.c
> and linux/drivers/input/mouse/sermouse.c
>
> Now it's your turn to decide.
>
> HTH
> T.
>
When I'm chosing option d) can smb. help me step by step? There are so
many pieces of code I don't understand.
Ok, let's begin:
my kernel source base is : ubuntu-lts 6.06 and 2.6.15-7
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.15.y.git;a=tree;f=drivers/input/serio;
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGXSKoAAomYJ1taN8RApggAJ99t+yMvPScr4yhOoTOS9TvYVUMsgCeJAbI
nGTvFGb49gUOzJG17Nmypq4=
=K4W8
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lars K.W. Gohlke schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tilman Schmidt schrieb:
>> Am 24.05.2007 21:15 schrieb Lars K.W. Gohlke:
>>> Jan Engelhardt schrieb:
>> [code proposal]
>>>> [I've warned about it... ;-) ]
>>> is it the way to access from kernelspace the userspace fs?
>>> the not-correct-way?
>>
>> Yes, indeed.
>>
>>> If it is so, I will wait for another solution ;)
>>
>> I'm not sure waiting will help. The roasted pigeons will not come
>> flying into your mouth.
>>
>> The possible solutions have been sketched out for you:
>>
>> a) open the device file from the kernel (described by Jan):
>> actively discouraged by the kernelnewbies.org FAQ document,
>> and probably won't even work IMHO
>>
>> b) program the serial port directly (described by Jan):
>> will work only with one type of hardware and you'll have to
>> disable the regular serial driver first; frowned upon by kernel
>> gurus as "reinventing the wheel"
>>
>> c) abuse the line discipline interface (described by me):
>> moderately well documented, and there's precedent for using it
>> that way in the well-accepted PPP module as well as my humble
>> contribution, the ser_gigaset driver; requires a userspace
>> daemon for pushing the line discipline module on the serial
>> port and keeping it there
>>
>> d) use the serio interface (described by Ying Huang):
>> potentially cleaner conceptually and seems to work without a
>> userspace daemon, but apparently not documented anywhere
>> except in the source files drivers/input/serio/serport.c
>> and linux/drivers/input/mouse/sermouse.c
>>
>> Now it's your turn to decide.
>>
>> HTH
>> T.
>>
>
> When I'm chosing option d) can smb. help me step by step? There are so
> many pieces of code I don't understand.
>
> Ok, let's begin:
>
> my kernel source base is : ubuntu-lts 6.06 and 2.6.15-7
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.15.y.git;a=tree;f=drivers/input/serio;
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
>
> iD8DBQFGXSKoAAomYJ1taN8RApggAJ99t+yMvPScr4yhOoTOS9TvYVUMsgCeJAbI
> nGTvFGb49gUOzJG17Nmypq4=
> =K4W8
> -----END PGP SIGNATURE-----
[linux/drivers/input/mouse/sermouse.c]
Where can I see, which serial line is used to get data stream from?
The mouse is plugged in. Where is the decision made, that maybe port0 is
used?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGXSvtAAomYJ1taN8RAjYtAKDfYqyK//u96/sxWMdLuUfRtMi2XwCg031C
lfEog7wFwd280dJeoqEZvu4=
=AH3F
-----END PGP SIGNATURE-----
Lars K.W. Gohlke schrieb:
> Lars K.W. Gohlke schrieb:
>> Tilman Schmidt schrieb:
[...]
>>> d) use the serio interface (described by Ying Huang):
>>> potentially cleaner conceptually and seems to work without a
>>> userspace daemon, but apparently not documented anywhere
>>> except in the source files drivers/input/serio/serport.c
>>> and linux/drivers/input/mouse/sermouse.c
>>>
>>> Now it's your turn to decide.
>
>> When I'm chosing option d) can smb. help me step by step? There are so
>> many pieces of code I don't understand.
That was Ying Huang's suggestion, so he might be best able to help
you. But I see you haven't included him in the recipient list of
your mail.
>> my kernel source base is : ubuntu-lts 6.06 and 2.6.15-7
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.15.y.git;a=tree;f=drivers/input/serio;
Perhaps it would be better to use a current kernel? It's always an
additional difficulty if one has to go back in history.
> [linux/drivers/input/mouse/sermouse.c]
>
> Where can I see, which serial line is used to get data stream from?
>
> The mouse is plugged in. Where is the decision made, that maybe port0 is
> used?
I have no idea. As I said, I have used a different interface and
this one is essentially undocumented. If I had to use it I would
probably try to follow the flow of control from the
serio_register_driver() call in sermouse_init() in order to see
where the .connect method ends up being called. But again, Ying
Huang was the one who suggested that interface, so hopefully he
might be able to tell you more.
HTH
T.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tilman Schmidt schrieb:
> Am 17.05.2007 08:15 schrieb huang ying:
>> I think the "serio" (through drivers/input/serio/serport.c) may be a
>> choice too, like that in linux/drivers/input/mouse/sermouse.c, which
>> is an example to program serial port in kernel space.
>
> Interesting. I wonder if that would have been a better choice for
> the Gigaset M101 driver. It seems even to have a probe mechanism
> so one could try to determine if the expected device is really
> connected to the port.
>
> Is there any documentation on this interface? I find the source a
> bit hard to understand, sparsely commented as it is.
>
> Thanks
> Tilman
>
how can I open ttyS1 with major=4 and minor=65?
Does anybody have some code to read from it the first e.g. 2bytes?
thx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGYySKAAomYJ1taN8RAsqpAKCEH/SXOwHuXcopa0cIGtpcE+yQeQCePzkg
gkODYbHe8Hwww9EhpE9+dco=
=BPGZ
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tilman Schmidt schrieb:
> Am 17.05.2007 08:15 schrieb huang ying:
>> I think the "serio" (through drivers/input/serio/serport.c) may be a
>> choice too, like that in linux/drivers/input/mouse/sermouse.c, which
>> is an example to program serial port in kernel space.
>
> Interesting. I wonder if that would have been a better choice for
> the Gigaset M101 driver. It seems even to have a probe mechanism
> so one could try to determine if the expected device is really
> connected to the port.
>
> Is there any documentation on this interface? I find the source a
> bit hard to understand, sparsely commented as it is.
>
> Thanks
> Tilman
>
how can I open ttyS1 with major=4 and minor=65?
Does anybody have some code to read from it the first e.g. 2bytes?
thx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD4DBQFGZRboAAomYJ1taN8RAkUQAJdOOvEOqXoiWPKd1cWLCpaksMkjAJ9QxH+w
sEIKnmL2TjPB53E1XkLQng==
=K9hA
-----END PGP SIGNATURE-----
Am 03.06.2007 22:28 schrieb Lars K.W. Gohlke:
> Tilman Schmidt schrieb:
>> Am 17.05.2007 08:15 schrieb huang ying:
>>> I think the "serio" (through drivers/input/serio/serport.c) may be a
>>> choice too, like that in linux/drivers/input/mouse/sermouse.c, which
>>> is an example to program serial port in kernel space.
>> Interesting. I wonder if that would have been a better choice for
>> the Gigaset M101 driver. It seems even to have a probe mechanism
>> so one could try to determine if the expected device is really
>> connected to the port.
>
>> Is there any documentation on this interface? I find the source a
>> bit hard to understand, sparsely commented as it is.
>
> how can I open ttyS1 with major=4 and minor=65?
a) With "my" approach, ie. writing a line discipline, you open
/dev/ttyS1 in a user space program and then push your line discipline
onto it using ioctl(,TIOCSETD,).
b) With the "serio" approach, if the probe mechanism is really what
I think it is, you register your probe function and wait for it to
be called for each active serial port, then do your thing to determine
whether this is a/the port you want to use.
> Does anybody have some code to read from it the first e.g. 2bytes?
That's not how things work in the kernel. You don't "read the first
<n> bytes" at will. You have to provide means to process whatever
data happens to arrive on the serial port, as it arrives.
a) With a line discipline, you provide a callback function
".receive_buf" which will be called by the serial driver if some
data has been received, and has to process that data then and there.
You might just stow it away in a buffer of course, provided you
are sure to get around to processing it later.
b) With the "serio" interface, it seems the ".interrupt" function
serves the same purpose - though, as I said, I am not really
competent on that topic.
HTH
T.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tilman Schmidt schrieb:
> Am 03.06.2007 22:28 schrieb Lars K.W. Gohlke:
>> Tilman Schmidt schrieb:
>>> Am 17.05.2007 08:15 schrieb huang ying:
>>>> I think the "serio" (through drivers/input/serio/serport.c) may be a
>>>> choice too, like that in linux/drivers/input/mouse/sermouse.c, which
>>>> is an example to program serial port in kernel space.
>>> Interesting. I wonder if that would have been a better choice for
>>> the Gigaset M101 driver. It seems even to have a probe mechanism
>>> so one could try to determine if the expected device is really
>>> connected to the port.
>>> Is there any documentation on this interface? I find the source a
>>> bit hard to understand, sparsely commented as it is.
>> how can I open ttyS1 with major=4 and minor=65?
>
> a) With "my" approach, ie. writing a line discipline, you open
> /dev/ttyS1 in a user space program and then push your line discipline
> onto it using ioctl(,TIOCSETD,).
>
> b) With the "serio" approach, if the probe mechanism is really what
> I think it is, you register your probe function and wait for it to
> be called for each active serial port, then do your thing to determine
> whether this is a/the port you want to use.
>
>> Does anybody have some code to read from it the first e.g. 2bytes?
>
> That's not how things work in the kernel. You don't "read the first
> <n> bytes" at will. You have to provide means to process whatever
> data happens to arrive on the serial port, as it arrives.
>
> a) With a line discipline, you provide a callback function
> ".receive_buf" which will be called by the serial driver if some
> data has been received, and has to process that data then and there.
> You might just stow it away in a buffer of course, provided you
> are sure to get around to processing it later.
>
> b) With the "serio" interface, it seems the ".interrupt" function
> serves the same purpose - though, as I said, I am not really
> competent on that topic.
>
> HTH
> T.
>
ok because I want to handle it in kernel space I will no take option a)
I will try it the way of b)
anyway thx.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGZm/aAAomYJ1taN8RAhS1AKC5xZVKXjZPAovXLmz2vuVr7JXssQCgqxs9
PUcqGC5sTzPtEzxuc5nkdes=
=qO4W
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lars K.W. Gohlke schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tilman Schmidt schrieb:
>> Am 03.06.2007 22:28 schrieb Lars K.W. Gohlke:
>>> Tilman Schmidt schrieb:
>>>> Am 17.05.2007 08:15 schrieb huang ying:
>>>>> I think the "serio" (through drivers/input/serio/serport.c) may be a
>>>>> choice too, like that in linux/drivers/input/mouse/sermouse.c, which
>>>>> is an example to program serial port in kernel space.
>>>> Interesting. I wonder if that would have been a better choice for
>>>> the Gigaset M101 driver. It seems even to have a probe mechanism
>>>> so one could try to determine if the expected device is really
>>>> connected to the port.
>>>> Is there any documentation on this interface? I find the source a
>>>> bit hard to understand, sparsely commented as it is.
>>> how can I open ttyS1 with major=4 and minor=65?
>>
>> a) With "my" approach, ie. writing a line discipline, you open
>> /dev/ttyS1 in a user space program and then push your line discipline
>> onto it using ioctl(,TIOCSETD,).
>>
>> b) With the "serio" approach, if the probe mechanism is really what
>> I think it is, you register your probe function and wait for it to
>> be called for each active serial port, then do your thing to determine
>> whether this is a/the port you want to use.
>>
>>> Does anybody have some code to read from it the first e.g. 2bytes?
>>
>> That's not how things work in the kernel. You don't "read the first
>> <n> bytes" at will. You have to provide means to process whatever
>> data happens to arrive on the serial port, as it arrives.
>>
>> a) With a line discipline, you provide a callback function
>> ".receive_buf" which will be called by the serial driver if some
>> data has been received, and has to process that data then and there.
>> You might just stow it away in a buffer of course, provided you
>> are sure to get around to processing it later.
>>
>> b) With the "serio" interface, it seems the ".interrupt" function
>> serves the same purpose - though, as I said, I am not really
>> competent on that topic.
>>
>> HTH
>> T.
>>
> ok because I want to handle it in kernel space I will no take option a)
>
> I will try it the way of b)
>
> anyway thx.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
>
> iD8DBQFGZm/aAAomYJ1taN8RAhS1AKC5xZVKXjZPAovXLmz2vuVr7JXssQCgqxs9
> PUcqGC5sTzPtEzxuc5nkdes=
> =qO4W
> -----END PGP SIGNATURE-----
I asked [email protected] as one of the driver developer
this is how I did it (just prototype)
(neccessary just one folder and two files)
1. copy template linux-source/drivers/input/joystick/magellan.c
2. insert in line 90 :
printk("%s:\"%s\"\n",__FUNCTION__, data);
3. make and insert it
4. inputattach --magellan /dev/ttyS0 &
5. date > /dev/ttyS0
6. dmesg | tail
voilà!
[output von dmesg]
[27336.486980] serio: Serial port ttyS0
[27336.487270] input: LogiCad3D Magellan / SpaceMouse as
/class/input/input6 [27336.518603] magellan_process_packet:"Mi 6 Jun
19:22:31 CEST 2007"
[/output]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGaIXNAAomYJ1taN8RAhHiAKDXAu4a/rKVS+Loz1Pqzo3mjWvlWACfZJje
q241AnJqNDn8q6YxQRB9lUU=
=CBPt
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I asked [email protected] as one of the driver developer
this is how I did it (just prototype, with implicite line discipline)
(neccessary just one folder and two files)
1. copy template linux-source/drivers/input/joystick/magellan.c
2. insert in line 90 :
printk("%s:\"%s\"\n",__FUNCTION__, data);
3. make and insert it
4. inputattach --magellan /dev/ttyS0 &
5. date > /dev/ttyS0
6. dmesg | tail
voil?!
[output von dmesg]
[27336.486980] serio: Serial port ttyS0
[27336.487270] input: LogiCad3D Magellan / SpaceMouse as
/class/input/input6 [27336.518603] magellan_process_packet:"Mi 6 Jun
19:22:31 CEST 2007"
[/output]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - GPGrelay v0.959
iD8DBQFGaIZbAAomYJ1taN8RAsMLAKDC1+OjCj+herKBXCNBknSu0K+uaACffNtk
Pdo0NVAjdBapHtg38m0u6Aw=
=DEP0
-----END PGP SIGNATURE-----
Am 08.06.2007 00:25 schrieb Lars K.W. Gohlke:
>>> a) With a line discipline, [...]
>>> b) With the "serio" interface, [...]
>>>
>> ok because I want to handle it in kernel space I will no take option a)
>
>> I will try it the way of b)
> I asked [email protected] as one of the driver developer
>
> this is how I did it (just prototype)
>
> (neccessary just one folder and two files)
> 1. copy template linux-source/drivers/input/joystick/magellan.c
> 2. insert in line 90 :
> printk("%s:\"%s\"\n",__FUNCTION__, data);
> 3. make and insert it
> 4. inputattach --magellan /dev/ttyS0 &
I see. So it turns out the "serio" interface finally goes through a
line discipline (N_MOUSE) and consequently also needs a userspace
daemon (inputattach). That doesn't give me any advantage compared
to attaching directly to the line discipline interface, so I'll
stay with the latter approach.
But glad to hear it worked out for you.
Take care,
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)