>>>>> "Dmitry" == Dmitry Torokhov <[email protected]> writes:
Dmitry> +static unsigned int i8042_aux_raw[4];
So, only AUX ports can be directly accessed? No direct access to
keyboard port? Why?
The SERIO_USERDEV patch does allow direct access to the PC AT
keyboard, and it did help me locate the SysRq problem that I reported
in other postings. i.e. it IS useful to be able to access the
keyboard port directly.
Dmitry> The driver will happily co-exist with psmouse and atkbd
Dmitry> loaded as they ignore SERIO_8042_RAW ports, so it is
Dmitry> possible to have one AUX port in raw mode and other in
Dmitry> standard 2.6 mode.
1) there is no RAW access to the keyboard port;
2) I hate this black magic, in which the input "devices"
(i.e. drivers) kidnap the serio ports they like according to the
port type SERIO_8042_RAW, etc. That's a kind of hardcoding the
binding between ports and drivers.
Isn't it better to leave the AUX ports as SERIO_8042, and let the user
dynamically change this port<-->driver binding? Then, we don't even
need that ugly "i8042.raw" boot parameter or i8042_aux_raw option.
The user can decide which ports are connected to your serio_raw
driver, and which ports are connected to psmouse.ko. That would also
allow multiple drivers driving the ports of the same type.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
On Wednesday 02 June 2004 04:49 am, Sau Dan Lee wrote:
> >>>>> "Dmitry" == Dmitry Torokhov <[email protected]> writes:
>
> Dmitry> +static unsigned int i8042_aux_raw[4];
>
> So, only AUX ports can be directly accessed? No direct access to
> keyboard port? Why?
>
Keyboards are to be handled in-kernel, at least for now. If there really
a need we can enable grabbing keyboard as well, no big deal.
> The SERIO_USERDEV patch does allow direct access to the PC AT
> keyboard, and it did help me locate the SysRq problem that I reported
> in other postings. i.e. it IS useful to be able to access the
> keyboard port directly.
>
Vojtech has a patch for that - now raw (really raw) codes are reported via
EV_MSC/MSC_RAW event.
>
> Dmitry> The driver will happily co-exist with psmouse and atkbd
> Dmitry> loaded as they ignore SERIO_8042_RAW ports, so it is
> Dmitry> possible to have one AUX port in raw mode and other in
> Dmitry> standard 2.6 mode.
>
> 1) there is no RAW access to the keyboard port;
>
> 2) I hate this black magic, in which the input "devices"
> (i.e. drivers) kidnap the serio ports they like according to the
> port type SERIO_8042_RAW, etc. That's a kind of hardcoding the
> binding between ports and drivers.
We do have some hardcoding so atkbd does not try to grab a serio linked
to a serial port and sermouse does not try grabbing keyboard port, etc..
There is nothing new.
>
>
> Isn't it better to leave the AUX ports as SERIO_8042, and let the user
> dynamically change this port<-->driver binding? Then, we don't even
> need that ugly "i8042.raw" boot parameter or i8042_aux_raw option.
> The user can decide which ports are connected to your serio_raw
> driver, and which ports are connected to psmouse.ko. That would also
> allow multiple drivers driving the ports of the same type.
>
Yes, that's the perfect solution, but I believe we need sysfs for that
and at least I started working on it, but it takes time. In the meantime
i8042.raw should alleviate most of the user's troubles with their input
devices no longer working.
--
Dmitry
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
The name fix on serio devices is as simply as the following example,
which can be applied to the 'atkbd' module. We just need to add back
the .name field to the 'struct serio_dev'. My previous patch can
detect this and use the meaningful name immediately!
--- linux-2.6.7-rc1/drivers/input/keyboard/atkbd.c 2004/06/01 07:45:00 1.2
+++ linux-2.6.7-rc1.name-fix/drivers/input/keyboard/atkbd.c 2004/06/02 17:44:47
@@ -818,20 +818,21 @@
atkbd_enable(atkbd);
if (atkbd_command(atkbd, param, ATKBD_CMD_SETLEDS))
return -1;
}
return 0;
}
static struct serio_dev atkbd_dev = {
+ .name = "atkbd",
.interrupt = atkbd_interrupt,
.connect = atkbd_connect,
.reconnect = atkbd_reconnect,
.disconnect = atkbd_disconnect,
.cleanup = atkbd_cleanup,
};
int __init atkbd_init(void)
{
serio_register_device(&atkbd_dev);
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
Sau Dan Lee wrote:
>
> I've added procfs support to serio.c, so that we can now control
> dynamically which serio ports connect to which serio devices. I call
> it "serio_switch", because it conceptually works like a patch panel or
> a switch with which you can rewire the connections.
Let me start with saying that this is a very good patch and that is
exactly what I have in mind with regard to serio port/device binding.
The only problem with the patch is that it uses wrong foundation, namely
procfs, because:
- procfs hierarchy is disconnected from the rest of the system. You
cannot trace device ownership starting with root PCI bus down to your
AUX port.
- there is no automatic hotplug notification to the userspace
- it is not flexible with regard to adding custom attributes to the
drivers. I can see you adding rate and resolution to psmouse driver
and repeat rate to atkbd. With sysfs drivers can themselves create
attributes and they will be cleaned up once device disappears. With
procfs you will have to export it form serio to be available to
drivers and cleanup can be a nightmare.
Of course sysfs has its "problems" - it requires users to follow certain
lifetime rules which are different from what serio uses at the moment.
So we have several options - if we adopt procfs based solution now we
will have to maintain it for very long time, along with competing sysfs
implementation. Dropping one kernel parameter which will never be widely
used is much easier, IMO.
So I propose we all join our ranks and tame that sysfs together ;) I had
some patches that were converting drivers to the sysfs adding them to
serio bus, I probably should just send what I have as is for review
(I was going to rediff them as they are somewhat stale, I'll see what
shape they are later tonight).
--
Dmitry
>>>>> "Dmitry" == Dmitry Torokhov <[email protected]> writes:
Dmitry> Let me start with saying that this is a very good patch
Dmitry> and that is exactly what I have in mind with regard to
Dmitry> serio port/device binding. The only problem with the
Dmitry> patch is that it uses wrong foundation, namely procfs,
Dmitry> because:
...
Dmitry> So we have several options - if we adopt procfs based
Dmitry> solution now we will have to maintain it for very long
Dmitry> time, along with competing sysfs implementation. Dropping
Dmitry> one kernel parameter which will never be widely used is
Dmitry> much easier, IMO.
It's not just the matter of dropping one kernel parameter. The procfs
support, _already implemented_, allows one to fine-tune the binding
between serio ports and devices, which is a new and useful feature
that your kernel parameter doesn't provide.
Can you unbind the keyboard port? Can you bind/unbind any of the AUX
ports *dynamically* without reloading the i8042 module? These
functionalities are already there in the serio-related code. Just a
userland interface is missing. My patch is to fill this gap.
Dmitry> So I propose we all join our ranks and tame that sysfs
Dmitry> together ;) I had some patches that were converting
Dmitry> drivers to the sysfs adding them to serio bus,
sysfs looks good for simple parameters: integers, strings. For
anything more complicated (sets, graphs), I don't see it fit (yet).
Unfortunately, the serio port<-->device relation is already a graph (1
to n).
I'd like to see how you implement the device<-->handler binding in
input.c using sysfs. It'd be a nice feature. Imagine how annoying it
is for 'evbug' to report your keypresses, when you're just debugging a
mouse driver. Being able to adjust the device<-->handler binding is
what I want. I don't care whether it's a procfs approach or sysfs
approach, as long as it is reasonably useable. (You could even do it
with ioctl(), if you provide a nice command line tool so that I don't
need to care about the ioctl parameters.) I'm not going to touch
input.c, because I don't want to reboot everytime to test a
modification. It's hard to compile input.c as a module.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
On Thursday 03 June 2004 12:54 am, Sau Dan Lee wrote:
> >>>>> "Dmitry" == Dmitry Torokhov <[email protected]> writes:
>
> Dmitry> Let me start with saying that this is a very good patch
> Dmitry> and that is exactly what I have in mind with regard to
> Dmitry> serio port/device binding. The only problem with the
> Dmitry> patch is that it uses wrong foundation, namely procfs,
> Dmitry> because:
> ...
>
> Dmitry> So we have several options - if we adopt procfs based
> Dmitry> solution now we will have to maintain it for very long
> Dmitry> time, along with competing sysfs implementation. Dropping
> Dmitry> one kernel parameter which will never be widely used is
> Dmitry> much easier, IMO.
>
> It's not just the matter of dropping one kernel parameter. The procfs
> support, _already implemented_, allows one to fine-tune the binding
> between serio ports and devices, which is a new and useful feature
> that your kernel parameter doesn't provide.
What I was trying to say is serio and input system will have sysfs support,
there is no question about that because sysfs _is_ the new driver model. So
by adopting procfs based solution we'll get ourselves 2 competing interfaces
for the same thing, just one will be very limited.
>
> Can you unbind the keyboard port? Can you bind/unbind any of the AUX
> ports *dynamically* without reloading the i8042 module? These
No, and I was not trying to. It is just a stop-gap measure to help end
users to get their PS/2 devices working until we have proper infrastructure
in place.
> functionalities are already there in the serio-related code. Just a
> userland interface is missing. My patch is to fill this gap.
>
>
>
> Dmitry> So I propose we all join our ranks and tame that sysfs
> Dmitry> together ;) I had some patches that were converting
> Dmitry> drivers to the sysfs adding them to serio bus,
>
> sysfs looks good for simple parameters: integers, strings. For
> anything more complicated (sets, graphs), I don't see it fit (yet).
> Unfortunately, the serio port<-->device relation is already a graph (1
> to n).
>
> I'd like to see how you implement the device<-->handler binding in
> input.c using sysfs.
Sysfs provides all the same features as procfs (I mean you write read/write
methods and have them do whatever you please) but it also has benefits of
your stuff integrating with the rest of devices into a hierarchy.
--
Dmitry
>>>>> "Dmitry" == Dmitry Torokhov <[email protected]> writes:
Dmitry> So we have several options - if we adopt procfs based
Dmitry> solution now we will have to maintain it for very long
Dmitry> time, along with competing sysfs implementation. Dropping
Dmitry> one kernel parameter which will never be widely used is
Dmitry> much easier, IMO.
>> It's not just the matter of dropping one kernel parameter.
>> The procfs support, _already implemented_, allows one to
>> fine-tune the binding between serio ports and devices, which is
>> a new and useful feature that your kernel parameter doesn't
>> provide.
Dmitry> What I was trying to say is serio and input system will
Dmitry> have sysfs support,
Then, why are you saying "dropping one kernel parameter"?
>> Can you unbind the keyboard port? Can you bind/unbind any of
>> the AUX ports *dynamically* without reloading the i8042 module?
>> These
Dmitry> No, and I was not trying to. It is just a stop-gap measure
Dmitry> to help end users to get their PS/2 devices working until
Dmitry> we have proper infrastructure in place.
I think direct access to PS/2 devices must stay there for the whole
2.6.x. It's unreasonable to assume that all existing _and working_
drivers will be kernelized.
>> sysfs looks good for simple parameters: integers, strings.
>> For anything more complicated (sets, graphs), I don't see it
>> fit (yet). Unfortunately, the serio port<-->device relation is
>> already a graph (1 to n).
>>
>> I'd like to see how you implement the device<-->handler binding
>> in input.c using sysfs.
Dmitry> Sysfs provides all the same features as procfs (I mean you
Dmitry> write read/write methods and have them do whatever you
Dmitry> please) but it also has benefits of your stuff integrating
Dmitry> with the rest of devices into a hierarchy.
It's different. Procfs is more versatile. I can stuff in my own
struct file_operations to do more than just read() and write(). I can
even stuff in my own struct inode_operations if I want more.
Another problem with sysfs is the "social" discipline as mentioned in
Documentation/filesystems/sysfs.txt:
Attributes should be ASCII text files, preferably with only
one value per file. It is noted that it may not be efficient
to contain only value per file, so it is socially acceptable
to express an array of values of the same type.
Mixing types, expressing multiple lines of data, and doing
fancy formatting of data is heavily frowned upon. Doing these
things may get you publically humiliated and your code
rewritten without notice.
It is common in procfs to format the output nicely, and to display
screenfuls of information. This is to be frowned upon in sysfs.
Currently implementations of sysfs interface do follow this rule
nicely.
Unfortunately, the connection between devices and drivers (either in
the serio.c interface or in the input.c interface) is a graph. It is
more complicated than an array. Yes, you can represent a graph with a
matrix or an adjacency list, both representable as arrays in one way
or another. Nothing in a digital computer cannot be represented by an
array of bits anyway! But useability of the interface must not be
ignored.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
On Thursday 03 June 2004 01:45 am, Sau Dan Lee wrote:
> >>>>> "Dmitry" == Dmitry Torokhov <[email protected]> writes:
>
> Dmitry> So we have several options - if we adopt procfs based
> Dmitry> solution now we will have to maintain it for very long
> Dmitry> time, along with competing sysfs implementation. Dropping
> Dmitry> one kernel parameter which will never be widely used is
> Dmitry> much easier, IMO.
>
> >> It's not just the matter of dropping one kernel parameter.
> >> The procfs support, _already implemented_, allows one to
> >> fine-tune the binding between serio ports and devices, which is
> >> a new and useful feature that your kernel parameter doesn't
> >> provide.
>
> Dmitry> What I was trying to say is serio and input system will
> Dmitry> have sysfs support,
>
> Then, why are you saying "dropping one kernel parameter"?
I am referring to possibly dropping i0842.raw once sysfs is implemeted
as then user will be able to rebind another driver to a port, like
your procfs patch does.
>
>
>
> >> Can you unbind the keyboard port? Can you bind/unbind any of
> >> the AUX ports *dynamically* without reloading the i8042 module?
> >> These
>
> Dmitry> No, and I was not trying to. It is just a stop-gap measure
> Dmitry> to help end users to get their PS/2 devices working until
> Dmitry> we have proper infrastructure in place.
>
> I think direct access to PS/2 devices must stay there for the whole
> 2.6.x. It's unreasonable to assume that all existing _and working_
> drivers will be kernelized.
>
>
>
> >> sysfs looks good for simple parameters: integers, strings.
> >> For anything more complicated (sets, graphs), I don't see it
> >> fit (yet). Unfortunately, the serio port<-->device relation is
> >> already a graph (1 to n).
> >>
> >> I'd like to see how you implement the device<-->handler binding
> >> in input.c using sysfs.
>
> Dmitry> Sysfs provides all the same features as procfs (I mean you
> Dmitry> write read/write methods and have them do whatever you
> Dmitry> please) but it also has benefits of your stuff integrating
> Dmitry> with the rest of devices into a hierarchy.
>
> It's different. Procfs is more versatile. I can stuff in my own
> struct file_operations to do more than just read() and write(). I can
> even stuff in my own struct inode_operations if I want more.
>
> Another problem with sysfs is the "social" discipline as mentioned in
> Documentation/filesystems/sysfs.txt:
>
> Attributes should be ASCII text files, preferably with only
> one value per file. It is noted that it may not be efficient
> to contain only value per file, so it is socially acceptable
> to express an array of values of the same type.
>
> Mixing types, expressing multiple lines of data, and doing
> fancy formatting of data is heavily frowned upon. Doing these
> things may get you publically humiliated and your code
> rewritten without notice.
>
> It is common in procfs to format the output nicely, and to display
> screenfuls of information. This is to be frowned upon in sysfs.
> Currently implementations of sysfs interface do follow this rule
> nicely.
>
> Unfortunately, the connection between devices and drivers (either in
> the serio.c interface or in the input.c interface) is a graph. It is
> more complicated than an array. Yes, you can represent a graph with a
> matrix or an adjacency list, both representable as arrays in one way
> or another. Nothing in a digital computer cannot be represented by an
> array of bits anyway! But useability of the interface must not be
> ignored.
>
I am not sure where you see the problem - consider a PCI bus and all PCI
devices and all drivers tyhat currently present in kernel. They are using
the new driver model and sysfs and they come together quite nicely.
--
Dmitry
>>>>> "Dmitry" == Dmitry Torokhov <[email protected]> writes:
>> Unfortunately, the connection between devices and drivers
>> (either in the serio.c interface or in the input.c interface)
>> is a graph. It is more complicated than an array. Yes, you
>> can represent a graph with a matrix or an adjacency list, both
>> representable as arrays in one way or another. Nothing in a
>> digital computer cannot be represented by an array of bits
>> anyway! But useability of the interface must not be ignored.
>>
Dmitry> I am not sure where you see the problem - consider a PCI
Dmitry> bus and all PCI devices and all drivers tyhat currently
Dmitry> present in kernel. They are using the new driver model and
Dmitry> sysfs and they come together quite nicely.
# ls -l /sys/bus/pci/devices/0000:01:00.0
-r--r--r-- 1 root root class
-rw-r--r-- 1 root root config
-rw-r--r-- 1 root root detach_state
-r--r--r-- 1 root root device
-r--r--r-- 1 root root irq
drwxr-xr-x 2 root root power
-r--r--r-- 1 root root resource
-r--r--r-- 1 root root subsystem_device
-r--r--r-- 1 root root subsystem_vendor
-r--r--r-- 1 root root vendor
# ls -l /sys/bus/pci/drivers/PIIX\ IDE
lrwxrwxrwx 1 root root 17:20 0000:00:07.1 ->
../../../../devices/pci0000:00/0000:00:07.1
--w------- 1 root root 17:20 new_id
The info are binary (shown in 0x???? notation). Each reflects
directly the binary value of the corresponding 'attribute'.
1) None of these are arrays. But in the input system, each device can
be attached to _multiple_ handlers, and each handler can handle
_multiple_ devices. That's an n-to-n relation.
2) I can't find out how to dynamically change the driver of a PCI
device.
3) PCI device<-->handler is a many-to-one relation. The input system
is many-to-many.
4) How to display/parse a device<-->handler connection? You want to
show and accept a pointer value?
The sysfs interface looks very confusing to me.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
On Thursday 03 June 2004 02:22 am, Sau Dan Lee wrote:
> >>>>> "Dmitry" == Dmitry Torokhov <[email protected]> writes:
>
> >> Unfortunately, the connection between devices and drivers
> >> (either in the serio.c interface or in the input.c interface)
> >> is a graph. It is more complicated than an array. Yes, you
> >> can represent a graph with a matrix or an adjacency list, both
> >> representable as arrays in one way or another. Nothing in a
> >> digital computer cannot be represented by an array of bits
> >> anyway! But useability of the interface must not be ignored.
> >>
>
> Dmitry> I am not sure where you see the problem - consider a PCI
> Dmitry> bus and all PCI devices and all drivers tyhat currently
> Dmitry> present in kernel. They are using the new driver model and
> Dmitry> sysfs and they come together quite nicely.
>
> # ls -l /sys/bus/pci/devices/0000:01:00.0
>
> -r--r--r-- 1 root root class
> -rw-r--r-- 1 root root config
> -rw-r--r-- 1 root root detach_state
> -r--r--r-- 1 root root device
> -r--r--r-- 1 root root irq
> drwxr-xr-x 2 root root power
> -r--r--r-- 1 root root resource
> -r--r--r-- 1 root root subsystem_device
> -r--r--r-- 1 root root subsystem_vendor
> -r--r--r-- 1 root root vendor
>
> # ls -l /sys/bus/pci/drivers/PIIX\ IDE
>
> lrwxrwxrwx 1 root root 17:20 0000:00:07.1 ->
> ../../../../devices/pci0000:00/0000:00:07.1
> --w------- 1 root root 17:20 new_id
>
>
> The info are binary (shown in 0x???? notation). Each reflects
> directly the binary value of the corresponding 'attribute'.
>
> 1) None of these are arrays. But in the input system, each device can
> be attached to _multiple_ handlers, and each handler can handle
> _multiple_ devices. That's an n-to-n relation.
And when they join together they form a new entity, a new device. And that's
input system, not serio.
>
> 2) I can't find out how to dynamically change the driver of a PCI
> device.
No need really. PCI devices are easily identifiable.
>
> 3) PCI device<-->handler is a many-to-one relation. The input system
> is many-to-many.
>
> 4) How to display/parse a device<-->handler connection? You want to
> show and accept a pointer value?
Strings are perfectly valid:
[dtor@core dtor]$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
acpi-cpufreq
[dtor@core dtor]$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
powersave userspace performance
It just depends on implementation.
>
> The sysfs interface looks very confusing to me.
>
Yes, I haven't wrapped my mind around it completely either. But we have
Greg K-H and others who will make sure we chose the right path ;)
--
Dmitry
>>>>> "Dmitry" == Dmitry Torokhov <[email protected]> writes:
>> The info are binary (shown in 0x???? notation). Each reflects
>> directly the binary value of the corresponding 'attribute'.
>>
>> 1) None of these are arrays. But in the input system, each
>> device can be attached to _multiple_ handlers, and each handler
>> can handle _multiple_ devices. That's an n-to-n relation.
Dmitry> And when they join together they form a new entity, a new
Dmitry> device. And that's input system, not serio.
No. The AT keyboard is still ONE device (cat /proc/bus/input/devices)
after loading 'evbug'. It is just connected to two handlers: kbd and
evbug. No new device is created just because the AT keyboard device
is joined to the evbug handler.
>> 2) I can't find out how to dynamically change the driver of a
>> PCI device.
Dmitry> No need really. PCI devices are easily identifiable.
Suppose there are 2 "competing" drivers for one device. I want to
switch the device to driver 2 at 23:00, and switch it back to driver 1
at 08:00. How to do that?
>> 3) PCI device<-->handler is a many-to-one relation. The input
>> system is many-to-many.
>>
>> 4) How to display/parse a device<-->handler connection? You
>> want to show and accept a pointer value?
Dmitry> Strings are perfectly valid:
Of course. What can't be represented as bit-strings?
Dmitry> $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
Dmitry> acpi-cpufreq
Dmitry> $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
Dmitry> powersave userspace performance
Dmitry> It just depends on implementation.
Then, go ahead an implement it. I have no interest in sysfs.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee