keymap rule selection for non-DMI platforms

keymap rule selection for non-DMI platforms

[Paul Fox]

hi --

OLPC's latest laptop (the 1.75 model) is ARM-based.  this means the
current keymap rule in rules.d/95-keymap.rules:

 ENV{DMI_VENDOR}="OLPC", ATTR{[dmi/id]product_name}="XO", \
 	RUN+="keymap $name olpc-xo"

won't trigger -- there's no DMI information.

any thoughts on how non-PC hardware should be identifying itself
to udev?  are there other examples of how this might be done?

i'm sure we could come up with something, based on examining some
other sysfs attribute, or perhaps running a command which identifies
our laptop(s), but i suspect this issue has come up before.

paul
=---------------------
 paul fox, pgf@laptop.org

Re: keymap rule selection for non-DMI platforms

[Paul Fox]

i wrote:
 > hi --
 > 
 > OLPC's latest laptop (the 1.75 model) is ARM-based.  this means the
 > current keymap rule in rules.d/95-keymap.rules:
 > 
 >  ENV{DMI_VENDOR}="OLPC", ATTR{[dmi/id]product_name}="XO", \
 >  	RUN+="keymap $name olpc-xo"
 > 
 > won't trigger -- there's no DMI information.
 > 
 > any thoughts on how non-PC hardware should be identifying itself
 > to udev?  are there other examples of how this might be done?
 > 
 > i'm sure we could come up with something, based on examining some
 > other sysfs attribute, or perhaps running a command which identifies
 > our laptop(s), but i suspect this issue has come up before.
 > 

since my initial query was met with such enthusiastic silence :-),
i've decided to try another approach.  attached is a (very tentative)
patch that supports our non-DMI laptop using a familiy-identifying
attribute found in /proc/device-tree.

essentially it adds a utility (currently in shell, but which will
trivially turn into C) that facilitates forming environment keys from
device-tree nodes.  this is then used in 95-keymap.rules to detect an
XO laptop and apply the right keymap.  the device-tree has always been
under /proc on linux -- it would probably make more sense under /sys,
but i'm not sure about the effort needed for, or the ramifications of,
such a move.

like i said, the attached constitutes a strawman approach.  hopefully
it will generate some thumbs, either up or down.

paul


commit ec4edb170cde845c7f710d98d7aceab2db729c53
Author: Paul Fox <pgf@laptop.org>
Date:   Tue Aug 16 14:26:55 2011 -0400

    tentative support for using device-tree attributes to identify a platform
    
    the new script device-tree-val is used in 95-keymap.rules to identify
    an OLPC XO laptop, based on the contents of /proc/device-tree/compatible

diff --git a/extras/device-tree/device-tree-val b/extras/device-tree/device-tree-val
new file mode 100644
index 0000000..46c884a
--- /dev/null
+++ b/extras/device-tree/device-tree-val
@@ -0,0 +1,21 @@
+#!/bin/sh
+
+dtree=/proc/device-tree
+
+usage()
+{
+	echo ${0##*/} key path >&2
+	exit 1
+}
+
+test $# = 2 || usage
+
+key="$1"
+path="$2"
+
+# 2nd arg must exist and be readable
+: < $dtree/$path || exit 1
+
+echo $key=$(cat $dtree/$path)
+
+
diff --git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 0d9b771..36d5d19 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -40,7 +40,7 @@ GOTO="keyboard_end"
 LABEL="keyboard_modulecheck"
 
 ENV{DMI_VENDOR}="$attr{[dmi/id]sys_vendor}"
-ENV{DMI_VENDOR}="", GOTO="keyboard_end"
+ENV{DMI_VENDOR}="", GOTO="keyboard_devicetree"
 
 ENV{DMI_VENDOR}="IBM*", KERNELS="input*", ATTRS{name}="ThinkPad Extra Buttons", RUN+="keymap $name module-ibm"
 ENV{DMI_VENDOR}="LENOVO*", KERNELS="input*", ATTRS{name}="ThinkPad Extra Buttons", RUN+="keymap $name module-lenovo"
@@ -156,5 +156,11 @@ ENV{DMI_VENDOR}="Everex", ATTR{[dmi/id]product_name}="XT5000*", RUN+="keymap $
 ENV{DMI_VENDOR}="COMPAL", ATTR{[dmi/id]product_name}="HEL80I", RUN+="keymap $name 0x84 wlan"
 
 ENV{DMI_VENDOR}="OLPC", ATTR{[dmi/id]product_name}="XO", RUN+="keymap $name olpc-xo"
+GOTO="keyboard_end"
+
+LABEL="keyboard_devicetree"
+
+IMPORT{command}="device-tree-val DEVTREE_COMPAT compatible"
+ENV{DEVTREE_COMPAT}="olpc,xo-1*", RUN+="keymap $name olpc-xo"
 
 LABEL="keyboard_end"
=---------------------
 paul fox, pgf@laptop.org

Re: keymap rule selection for non-DMI platforms

[Kay Sievers]

On Tue, Aug 16, 2011 at 20:54, Paul Fox <pgf@laptop.org> wrote:
> since my initial query was met with such enthusiastic silence :-),

Yeah, I guess we all mostly focus on x86 and similar.

> i've decided to try another approach.  attached is a (very tentative)
> patch that supports our non-DMI laptop using a familiy-identifying
> attribute found in /proc/device-tree.
>
> essentially it adds a utility (currently in shell, but which will
> trivially turn into C) that facilitates forming environment keys from
> device-tree nodes.  this is then used in 95-keymap.rules to detect an
> XO laptop and apply the right keymap.  the device-tree has always been
> under /proc on linux -- it would probably make more sense under /sys,
> but i'm not sure about the effort needed for, or the ramifications of,
> such a move.

Reading such things from /proc is kinda taboo from code we maintain in
udev. All things not related to processes really do not belong into
/proc and udev code should never get into the way of possibly
deprecating these things in the long run, even when they might never
happen. I know, there is sometimes no other simple option, but we
generally prefer the inconvenience it causes, over adding hacks to
upstream code, to make a move to a generally useful solution (which
isn't /proc/*) more attractive.

I guess one sensible option is to register the /sys/class/dmi
interface to ARM too, even when it's not called that way for ARM
hardware. 'Desktop Management Interface' makes not much sense anyway,
not even for x86, but hey it's only 3 characters, whatever they mean.
:)

The alternative is to replace /sys/class/dmi with some completely arch
and platform independent interface and export there what dmi currently
supports and plug-in the other platforms.

I'm very convinced that userspace should not even try to work around
platforms that miss proper interfaces which can be used to easily
match against system properties.

Kay

Re: keymap rule selection for non-DMI platforms

[Daniel Drake]

On Tue, Aug 16, 2011 at 8:34 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> Reading such things from /proc is kinda taboo from code we maintain in
> udev. All things not related to processes really do not belong into
> /proc and udev code should never get into the way of possibly
> deprecating these things in the long run, even when they might never
> happen. I know, there is sometimes no other simple option, but we
> generally prefer the inconvenience it causes, over adding hacks to
> upstream code, to make a move to a generally useful solution (which
> isn't /proc/*) more attractive.

I agree that the use of /proc is strange, but just to make sure you
understand: /proc/device-tree is a standard upstream kernel thing and
has been for a long time. It is not some OLPC-specific oddity to
access our manufacturing data. It is *the* way to access device tree
info on ARM, PPC, SPARC (and x86). And device tree is specifically
built as a way of identifying hardware info which the silicon can't
tell you. udev implementing support for device tree will solve OLPC's
keyboard identification issue, but you'll also solve a whole class of
problems for the wide range of platforms that use device tree (and
those that will soon use it).

> I guess one sensible option is to register the /sys/class/dmi
> interface to ARM too, even when it's not called that way for ARM
> hardware. 'Desktop Management Interface' makes not much sense anyway,
> not even for x86, but hey it's only 3 characters, whatever they mean.
> :)

I think you're too late to suggest a new solution to this problem.
This is exactly what device tree is for, and Linux has been steadily
going in this direction for a while.

However, the location inside of /proc is certainly something that can
be criticised.

> The alternative is to replace /sys/class/dmi with some completely arch
> and platform independent interface and export there what dmi currently
> supports and plug-in the other platforms.

Device tree is already arch and platform independent, but I'm not sure
how you would make DMI info look like a device tree. Despite both
being able to provide identification info, they are quite different
beasts.

Daniel

Re: keymap rule selection for non-DMI platforms

[Kay Sievers]

On Tue, Aug 16, 2011 at 22:09, Daniel Drake <dsd@laptop.org> wrote:
> On Tue, Aug 16, 2011 at 8:34 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> Reading such things from /proc is kinda taboo from code we maintain in
>> udev. All things not related to processes really do not belong into
>> /proc and udev code should never get into the way of possibly
>> deprecating these things in the long run, even when they might never
>> happen. I know, there is sometimes no other simple option, but we
>> generally prefer the inconvenience it causes, over adding hacks to
>> upstream code, to make a move to a generally useful solution (which
>> isn't /proc/*) more attractive.
>
> I agree that the use of /proc is strange, but just to make sure you
> understand: /proc/device-tree is a standard upstream kernel thing and
> has been for a long time. It is not some OLPC-specific oddity to
> access our manufacturing data. It is *the* way to access device tree
> info on ARM, PPC, SPARC (and x86). And device tree is specifically
> built as a way of identifying hardware info which the silicon can't
> tell you. udev implementing support for device tree will solve OLPC's
> keyboard identification issue, but you'll also solve a whole class of
> problems for the wide range of platforms that use device tree (and
> those that will soon use it).

That might all be true, I don't complain, it's just that udev upstream
does not read things like that from /proc, no matter how common the
use is.

Stuff belongs into /sys/firmware/ /sys/wherever not /proc, and udev
can not read things like that from /proc because that would prevent
anybody from ever fixing it with the argument that one of the main
components relies on it.

>> I guess one sensible option is to register the /sys/class/dmi
>> interface to ARM too, even when it's not called that way for ARM
>> hardware. 'Desktop Management Interface' makes not much sense anyway,
>> not even for x86, but hey it's only 3 characters, whatever they mean.
>> :)
>
> I think you're too late to suggest a new solution to this problem.
> This is exactly what device tree is for, and Linux has been steadily
> going in this direction for a while.

Sure, if there is something we all can use, we will switch over to it.
Until that happens, hacks have to be maintained by the people relying
on them, not by udev upstream.

> However, the location inside of /proc is certainly something that can
> be criticised.

It's just nothing udev will use. Archs can do what they think it's
right, and they might be right, I'll not argue here.

But userspace should step back working around such things, and people
should start working on the 'proper' solution.

>> The alternative is to replace /sys/class/dmi with some completely arch
>> and platform independent interface and export there what dmi currently
>> supports and plug-in the other platforms.
>
> Device tree is already arch and platform independent, but I'm not sure
> how you would make DMI info look like a device tree. Despite both
> being able to provide identification info, they are quite different
> beasts.

Well, then upstream udev will wait for the common solution. :)

Kay

Re: keymap rule selection for non-DMI platforms

[Daniel Drake]

On Tue, Aug 16, 2011 at 9:30 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> Sure, if there is something we all can use, we will switch over to it.
> Until that happens, hacks have to be maintained by the people relying
> on them, not by udev upstream.

You can use it. Just like many platforms (of varying architectures)
already do in other contexts, all using unmodified Linus kernels.

Device tree is a well-documented cross-platform way of providing
hardware identification information (and in great detail) to the
kernel. I think it is the system you are asking for. Am I right in
saying that its location in /proc is the main downfall that you are
criticising it for? (i.e. would your viewpoint change if it appeared
in /sys tomorrow?)

Daniel

Re: keymap rule selection for non-DMI platforms

[Paul Fox]

kay wrote:
 > On Tue, Aug 16, 2011 at 22:09, Daniel Drake <dsd@laptop.org> wrote:
 > > On Tue, Aug 16, 2011 at 8:34 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
 > >> Reading such things from /proc is kinda taboo from code we maintain in
 > >> udev. All things not related to processes really do not belong into
 > >> /proc and udev code should never get into the way of possibly
 > >> deprecating these things in the long run, even when they might never
 > >> happen. I know, there is sometimes no other simple option, but we
 > >> generally prefer the inconvenience it causes, over adding hacks to
 > >> upstream code, to make a move to a generally useful solution (which
 > >> isn't /proc/*) more attractive.
 > >
 > > I agree that the use of /proc is strange, but just to make sure you
 > > understand: /proc/device-tree is a standard upstream kernel thing and
 > > has been for a long time. It is not some OLPC-specific oddity to
 > > access our manufacturing data. It is *the* way to access device tree
 > > info on ARM, PPC, SPARC (and x86). And device tree is specifically
 > > built as a way of identifying hardware info which the silicon can't
 > > tell you. udev implementing support for device tree will solve OLPC's
 > > keyboard identification issue, but you'll also solve a whole class of
 > > problems for the wide range of platforms that use device tree (and
 > > those that will soon use it).
 > 
 > That might all be true, I don't complain, it's just that udev upstream
 > does not read things like that from /proc, no matter how common the
 > use is.
 > 
 > Stuff belongs into /sys/firmware/ /sys/wherever not /proc, and udev
 > can not read things like that from /proc because that would prevent
 > anybody from ever fixing it with the argument that one of the main
 > components relies on it.

so just to be sure i understand your objection:  if /proc/device-tree
were to move to /sys/device-tree (or similar path, and perhaps be
doubly mounted there during a transition period), it would be
acceptable to propose that udev start using it?

paul

 > 
 > >> I guess one sensible option is to register the /sys/class/dmi
 > >> interface to ARM too, even when it's not called that way for ARM
 > >> hardware. 'Desktop Management Interface' makes not much sense anyway,
 > >> not even for x86, but hey it's only 3 characters, whatever they mean.
 > >> :)
 > >
 > > I think you're too late to suggest a new solution to this problem.
 > > This is exactly what device tree is for, and Linux has been steadily
 > > going in this direction for a while.
 > 
 > Sure, if there is something we all can use, we will switch over to it.
 > Until that happens, hacks have to be maintained by the people relying
 > on them, not by udev upstream.
 > 
 > > However, the location inside of /proc is certainly something that can
 > > be criticised.
 > 
 > It's just nothing udev will use. Archs can do what they think it's
 > right, and they might be right, I'll not argue here.
 > 
 > But userspace should step back working around such things, and people
 > should start working on the 'proper' solution.
 > 
 > >> The alternative is to replace /sys/class/dmi with some completely arch
 > >> and platform independent interface and export there what dmi currently
 > >> supports and plug-in the other platforms.
 > >
 > > Device tree is already arch and platform independent, but I'm not sure
 > > how you would make DMI info look like a device tree. Despite both
 > > being able to provide identification info, they are quite different
 > > beasts.
 > 
 > Well, then upstream udev will wait for the common solution. :)
 > 
 > Kay

=---------------------
 paul fox, pgf@laptop.org

Re: keymap rule selection for non-DMI platforms

[Greg KH]

On Tue, Aug 16, 2011 at 09:39:37PM +0100, Daniel Drake wrote:
> On Tue, Aug 16, 2011 at 9:30 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > Sure, if there is something we all can use, we will switch over to it.
> > Until that happens, hacks have to be maintained by the people relying
> > on them, not by udev upstream.
> 
> You can use it. Just like many platforms (of varying architectures)
> already do in other contexts, all using unmodified Linus kernels.
> 
> Device tree is a well-documented cross-platform way of providing
> hardware identification information (and in great detail) to the
> kernel. I think it is the system you are asking for. Am I right in
> saying that its location in /proc is the main downfall that you are
> criticising it for? (i.e. would your viewpoint change if it appeared
> in /sys tomorrow?)

What about all of the existing device tree work that has been going on
in the kernel for the past year?  It should be in sysfs already, so why
not just use those files instead?

As for DMI being "desktop" specific, others agree, and tried to write
patches to rename everything.  I think they were rightly shot down as it
would have broken lots of userspace code, so there's no problem with
putting this type of information into the dmi "namespace" as it is.

greg k-h

Re: keymap rule selection for non-DMI platforms

[Kay Sievers]

On Tue, Aug 16, 2011 at 22:39, Daniel Drake <dsd@laptop.org> wrote:
> On Tue, Aug 16, 2011 at 9:30 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> Sure, if there is something we all can use, we will switch over to it.
>> Until that happens, hacks have to be maintained by the people relying
>> on them, not by udev upstream.
>
> You can use it. Just like many platforms (of varying architectures)
> already do in other contexts, all using unmodified Linus kernels.
>
> Device tree is a well-documented cross-platform way of providing
> hardware identification information (and in great detail) to the
> kernel. I think it is the system you are asking for.

We are not discussing the usefulness or completeness of any 'device
tree' here. That's an unrelated issue.

It's about a dead simple 'machine identification' that can be
retrieved without jumping through hoops.

x86 also does not need to look in the ACPI tree for matching up the
keymap, it has a simple interface to export hardware parameters in a
sane format. There is no reason other platforms can't do the same.

> Am I right in
> saying that its location in /proc is the main downfall that you are
> criticising it for? (i.e. would your viewpoint change if it appeared
> in /sys tomorrow?)

Sure, but probably not a single file, it can not move to /sys.

Kay

Re: keymap rule selection for non-DMI platforms

[Kay Sievers]

On Tue, Aug 16, 2011 at 22:49, Paul Fox <pgf@laptop.org> wrote:
> kay wrote:
>  > On Tue, Aug 16, 2011 at 22:09, Daniel Drake <dsd@laptop.org> wrote:
>  > > On Tue, Aug 16, 2011 at 8:34 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>  > >> Reading such things from /proc is kinda taboo from code we maintain in
>  > >> udev. All things not related to processes really do not belong into
>  > >> /proc and udev code should never get into the way of possibly
>  > >> deprecating these things in the long run, even when they might never
>  > >> happen. I know, there is sometimes no other simple option, but we
>  > >> generally prefer the inconvenience it causes, over adding hacks to
>  > >> upstream code, to make a move to a generally useful solution (which
>  > >> isn't /proc/*) more attractive.
>  > >
>  > > I agree that the use of /proc is strange, but just to make sure you
>  > > understand: /proc/device-tree is a standard upstream kernel thing and
>  > > has been for a long time. It is not some OLPC-specific oddity to
>  > > access our manufacturing data. It is *the* way to access device tree
>  > > info on ARM, PPC, SPARC (and x86). And device tree is specifically
>  > > built as a way of identifying hardware info which the silicon can't
>  > > tell you. udev implementing support for device tree will solve OLPC's
>  > > keyboard identification issue, but you'll also solve a whole class of
>  > > problems for the wide range of platforms that use device tree (and
>  > > those that will soon use it).
>  >
>  > That might all be true, I don't complain, it's just that udev upstream
>  > does not read things like that from /proc, no matter how common the
>  > use is.
>  >
>  > Stuff belongs into /sys/firmware/ /sys/wherever not /proc, and udev
>  > can not read things like that from /proc because that would prevent
>  > anybody from ever fixing it with the argument that one of the main
>  > components relies on it.
>
> so just to be sure i understand your objection:  if /proc/device-tree
> were to move to /sys/device-tree (or similar path,

It has to fit into the way /sys is layouted, which is usually very
different from /proc.

> and perhaps be
> doubly mounted there during a transition period)

No, we also don't accept double mount tricks here.

> it would be
> acceptable to propose that udev start using it?

No, sorry, the time for dirty hacks in userspace, and work-arounds for
architectures and platforms that don't provide what is commonly used
elsewhere is over. There is no rush, it's new functionality, and no
need to start with 'transitions periods' that in reality will never
end. Stuff just needs to be fixed properly these days, and papering
over just hurts us more in the end.

The fix should be simple enough, we do not look for ACPI tree or the
ARM device tree couterpart, we look for a simple, well-defined
'machine id' export. That's what class 'dmi' is on x86. Either ARM
exports the same format, or we come up with something new for
everybody which we all swich over to.

Kay

Re: keymap rule selection for non-DMI platforms

[Kay Sievers]

On Tue, Aug 16, 2011 at 23:47, Greg KH <greg@kroah.com> wrote:
> On Tue, Aug 16, 2011 at 09:39:37PM +0100, Daniel Drake wrote:
>> On Tue, Aug 16, 2011 at 9:30 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> > Sure, if there is something we all can use, we will switch over to it.
>> > Until that happens, hacks have to be maintained by the people relying
>> > on them, not by udev upstream.
>>
>> You can use it. Just like many platforms (of varying architectures)
>> already do in other contexts, all using unmodified Linus kernels.
>>
>> Device tree is a well-documented cross-platform way of providing
>> hardware identification information (and in great detail) to the
>> kernel. I think it is the system you are asking for. Am I right in
>> saying that its location in /proc is the main downfall that you are
>> criticising it for? (i.e. would your viewpoint change if it appeared
>> in /sys tomorrow?)
>
> What about all of the existing device tree work that has been going on
> in the kernel for the past year?  It should be in sysfs already, so why
> not just use those files instead?
>
> As for DMI being "desktop" specific, others agree, and tried to write
> patches to rename everything.  I think they were rightly shot down as it
> would have broken lots of userspace code, so there's no problem with
> putting this type of information into the dmi "namespace" as it is.

Yeah, we should probably read it as "Digital Machine Identification"
and just let all platforms export it. Stuff would magically just work
out-of--the-box. :)

Kay

Re: keymap rule selection for non-DMI platforms

[Daniel Drake]

On Tue, Aug 16, 2011 at 11:34 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> It has to fit into the way /sys is layouted, which is usually very
> different from /proc.

Right. And the challenge here is that devicetree sits above the
kernel's device layer (raising questions on exactly how to represent
it in /sys, without creating a container filesystem for /sys itself),
where DMI is (hackishly, IMO) exposed as a virtual device
(/sys/devices/virtual). Doing the same trick with DT would be bizarre
from the kernel standpoint.

> No, sorry, the time for dirty hacks in userspace, and work-arounds for
> architectures and platforms that don't provide what is commonly used
> elsewhere is over. There is no rush, it's new functionality, and no
> need to start with 'transitions periods' that in reality will never
> end. Stuff just needs to be fixed properly these days, and papering
> over just hurts us more in the end.

Not wanting to criticise any future unified system ideas, I just want
to point out that devicetree predates both udev and /sys. It is not
new. Your same arguments could be applied to DMI, which is new in
comparison, limited in the data it can represent, strangely exposed in
the kernel's representation of devices, and platform-specific. Yet DMI
and its imperfections already "won" udev, maybe just because of x86
popularity, so I guess that argument is not so interesting.

> The fix should be simple enough, we do not look for ACPI tree or the
> ARM device tree couterpart, we look for a simple, well-defined
> 'machine id' export. That's what class 'dmi' is on x86. Either ARM
> exports the same format, or we come up with something new for
> everybody which we all swich over to.

OK, now I think I understand what you are getting at. A generic sysfs
interface that could be fed by either (a part of) DMI or (a very small
part of) devicetree, which exposes bare-bones details like vendor and
product. That could indeed solve the problem at hand.

However, to complicate things further with another item on our TODO
list: OLPC offers the same identical laptop models with two alternate
keyboards - membrane and mechanical. This is for both x86 and ARM
models. At the moment, we use the same keymap for both even despite
differences in the keys, but we plan to improve on this in future
since it is a bug that keys do not behave according to the symbols
printed on them!

There is no other difference in the laptop other than the keyboard, so
this information could not be captured in the bare-bones info
presented in DMI or by the theoretical system mentioned above, unless
we were to do something hacky like encode the keyboard model in the
product_name. And, you guessed it, info on which type of keyboard is
installed comes from a devicetree node.

Daniel

Re: Re: keymap rule selection for non-DMI platforms

[Prarit Bhargava]

On 01/-10/-28163 02:59 PM, Kay Sievers wrote:
> On Tue, Aug 16, 2011 at 23:47, Greg KH <greg@kroah.com> wrote:
>> On Tue, Aug 16, 2011 at 09:39:37PM +0100, Daniel Drake wrote:
>>> On Tue, Aug 16, 2011 at 9:30 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>>> Sure, if there is something we all can use, we will switch over to it.
>>>> Until that happens, hacks have to be maintained by the people relying
>>>> on them, not by udev upstream.
>>>
>>> You can use it. Just like many platforms (of varying architectures)
>>> already do in other contexts, all using unmodified Linus kernels.
>>>
>>> Device tree is a well-documented cross-platform way of providing
>>> hardware identification information (and in great detail) to the
>>> kernel. I think it is the system you are asking for. Am I right in
>>> saying that its location in /proc is the main downfall that you are
>>> criticising it for? (i.e. would your viewpoint change if it appeared
>>> in /sys tomorrow?)
>>
>> What about all of the existing device tree work that has been going on
>> in the kernel for the past year?  It should be in sysfs already, so why
>> not just use those files instead?
>>
>> As for DMI being "desktop" specific, others agree, and tried to write
>> patches to rename everything.  I think they were rightly shot down as it
>> would have broken lots of userspace code, so there's no problem with
>> putting this type of information into the dmi "namespace" as it is.

That was me.  Thanks Kay for pointing me to this thread.  

The problem with the re-write was that people objected to a unified system interface in which different architecture's firmware could be exposed.  The main issue was that the only two that "really" required this functionality were ia64 and x86.  powerpc *could* make use of the interface but it wasn't a necessity as it is in the ia64 and x86 arches.

> 
> Yeah, we should probably read it as "Digital Machine Identification"
> and just let all platforms export it. Stuff would magically just work
> out-of--the-box. :)
> 

Kay, sometimes the best ideas come from jokes :) ... that doesn't sound as bad as you would think!  Going back to my [v3] here

http://marc.info/?l=linux-kernel&m\x131099454831224&w=2

reworking the System Firmware Interface into a Digital Machine Identification layer would

a) resolve Paul's ARM problem discussed in this thread,
b) *DRAMATICALLY* cut down on the size of that patchset.  95% of it is s/DMI/SYSFW/g.

Paul -- what do you think?  If I provided you a clean patchset in the next week or so would you be willing to implement the ARM functionality?  Of course I would be more than willing to help ...

We could push it together and see where that goes.

P.

Re: keymap rule selection for non-DMI platforms

[Karl O. Pinc]

On 08/16/2011 05:54:04 PM, Daniel Drake wrote:

> However, to complicate things further with another item on our TODO
> list: OLPC offers the same identical laptop models with two alternate
> keyboards - membrane and mechanical. This is for both x86 and ARM
> models. At the moment, we use the same keymap for both even despite
> differences in the keys, but we plan to improve on this in future
> since it is a bug that keys do not behave according to the symbols
> printed on them!
> 
> There is no other difference in the laptop other than the keyboard, 
> so
> this information could not be captured in the bare-bones info
> presented in DMI or by the theoretical system mentioned above, unless
> we were to do something hacky like encode the keyboard model in the
> product_name.

I don't understand.

Why is it a hack to encode the keyboard model in the product name?
When the keyboard is part of the product and there's two different
keyboards (not just mechanically, but with different keymaps)
why isn't it 2 product models?



Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: keymap rule selection for non-DMI platforms

[Paul Fox]

karl o. pinc wrote:
 > On 08/16/2011 05:54:04 PM, Daniel Drake wrote:
 > 
 > > However, to complicate things further with another item on our TODO
 > > list: OLPC offers the same identical laptop models with two alternate
 > > keyboards - membrane and mechanical. This is for both x86 and ARM
 > > models. At the moment, we use the same keymap for both even despite
 > > differences in the keys, but we plan to improve on this in future
 > > since it is a bug that keys do not behave according to the symbols
 > > printed on them!
 > > 
 > > There is no other difference in the laptop other than the keyboard, 
 > > so
 > > this information could not be captured in the bare-bones info
 > > presented in DMI or by the theoretical system mentioned above, unless
 > > we were to do something hacky like encode the keyboard model in the
 > > product_name.
 > 
 > I don't understand.
 > 
 > Why is it a hack to encode the keyboard model in the product name?
 > When the keyboard is part of the product and there's two different
 > keyboards (not just mechanically, but with different keymaps)
 > why isn't it 2 product models?

we have three laptop models, and something like 20 different
keyboards.  whether or not they all need different keymaps (they
don't), i think you can see why we might not necessarily encode any
of them as different models.

paul
=---------------------
 paul fox, pgf@laptop.org