LKML Archive on
help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <>
To: Yan Burman <>
Cc: Shem Multinymous <>,,,
	Pavel Machek <>
Subject: Re: [Hdaps-devel] [PATCH 2.6.23-rc2] hwmon: HP Mobile Data Protection System 3D ACPI driver (resend)
Date: Thu, 30 Aug 2007 13:41:32 -0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, 30 Aug 2007, Yan Burman wrote:
>>> You can generate events on input devices, but I am not sure that's the
>>> best way to go about it for this.  Things that block on read until an
>>> interrupt happens might work better.
>> You can do the latter via another (4th) input device.
> What's wrong with the stuff I did in mdps? a misc character device that
> acts like /dev/rtc. Why does it have to be input device oriented?

I am fine with a char device that acts like /dev/rtc, but if we are doing
something as heavyweight as a char device, I'd rather we go full generic
netlink and send the various events over it.  We'd have a netlink device
that sends everything over various "channels" and just one input device that
does joystick emulation, then.

Can we use a simple sysfs attribute that blocks the caller on write and
returns immediately on read? If it has to be more complicated than that, I'd
rather we go the netlink path. Any other ideas that are not a char device,
not a netlink socket, not an input device node, and not a sysfs attribute?

> I also looked at what you did in the patches as well as the modified 
> hdapsd. I'm doing the raw input device right now in the mdps, but I have a 
> suggestion.
> It seems to me that right now there are at least 3 drivers that provide the 
> same functionality - hdaps, ams and mdps. Why not create the input device
> that exports raw accelerometer data with a name that is generic - something 
> like accel/input or something along those lines. This way hdapsd could work
> with any driver that provides the functionality without being hdaps 
> specific.

THAT is the idea, IMO.  But the naming is userspace's problem (thorugh
udev), not ours :-)

Or do you mean the "hardware port" part of the input device? If so, yes, we
should try to make standard names for those as that makes it easier for

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

  reply	other threads:[~2007-08-30 16:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-11 11:26 Yan Burman
2007-08-11 17:14 ` Henrique de Moraes Holschuh
2007-08-25 10:25 ` Pavel Machek
2007-08-25 11:36   ` Yan Burman
2007-08-27  8:28     ` Pavel Machek
2007-08-27 17:11     ` Henrique de Moraes Holschuh
2007-08-29 17:05       ` Yan Burman
2007-08-29 23:30         ` [Hdaps-devel] " Henrique de Moraes Holschuh
2007-08-30  0:31           ` Shem Multinymous
2007-08-30 12:42             ` Henrique de Moraes Holschuh
2007-08-30 15:44             ` Yan Burman
2007-08-30 16:41               ` Henrique de Moraes Holschuh [this message]
2007-08-30 19:39                 ` Kay Sievers
2007-09-10 20:18                 ` Yan Burman
2007-09-10 22:55                   ` Henrique de Moraes Holschuh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [Hdaps-devel] [PATCH 2.6.23-rc2] hwmon: HP Mobile Data Protection System 3D ACPI driver (resend)' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).