Prev: tracing: Fix infinite loop in ftrace_update_pid_func()
Next: cpu affinity issue on kvm-88
From: Thadeu Lima de Souza Cascardo on 30 Sep 2009 15:00
On Wed, Sep 30, 2009 at 12:27:48PM -0600, Bjorn Helgaas wrote:
> On Wednesday 30 September 2009 11:51:43 am Thadeu Lima de Souza Cascardo wrote:
> > On Wed, Sep 30, 2009 at 09:50:38AM -0600, Bjorn Helgaas wrote:
> > > On Monday 28 September 2009 07:38:00 pm Thadeu Lima de Souza Cascardo wrote:
> > > > This add supports for devices like keyboard, backlight, tablet and
> > > > accelerometer.
> > >
> > > Something about the PNP IDs bothered me yesterday, but I couldn't
> > > figure out what. You're using:
> > >
> > > ACCE0000
> > > TBLT0000
> > > IPML200
> > > FnBT0000
> > >
> > > Normally these OEM-specific ACPI drivers claim PNP IDs like ATK0100,
> > > TOS6200, FUJ02B1, etc., that are obviously OEM-specific.
> > >
> > > But the ones you're claiming seem pretty generic, like things
> > > we could imagine appearing on machines other than the Classmate.
> > >
> > > So I guess my question is, "Are these really generic? If so, should
> > > this be split into separate, non-Classmate named drivers, such as
> > > 'accelerometer', 'tablet', etc.?"
> > >
> >
> > Although I agree that {ATK,TOS,FUJ,IBM}* give pretty much a certainty
> > these are OEM-specific, I think we'd need some evidence that
> > {ACCE,TBLT,IPML,FnBT}* are generic enough to grant them a non-classmate
> > driver.
> >
> > What I mean is that we should push this driver forward and turn these
> > into a generic driver if we get some evidence these are not
> > Classmate-specific. And that will happen when we hit some other system
> > with these devices.
>
> Yep, I agree with you that it's not worth splitting things up until
> we find these devices on more systems. Just out of curiosity, where
> did you find specs for these devices? If there's a public spec, it'd
> be nice to have a pointer to it in the driver.
>
> Bjorn

There was no public spec. I used as reference some source code released
as GPL. This implementation used proc files as user interface. Other
references are the dumped tables, which I am using to implement what is
very likely a rfkill device. We are still doing some tests before adding
it to the driver.

Regards,
Cascardo.
From: Dmitry Torokhov on 1 Oct 2009 13:20
On Tue, Sep 29, 2009 at 05:41:42PM +0100, Alan Jenkins wrote:
> On 9/29/09, Thadeu Lima de Souza Cascardo <cascardo(a)holoscopio.com> wrote:
>
> >> > +static void cmpc_tablet_idev_init(struct input_dev *inputdev)
> >> > +{
> >> > + set_bit(EV_SW, inputdev->evbit);
> >> > + set_bit(SW_TABLET_MODE, inputdev->swbit);
> >>
> >> Don't you need to initialize the switch value here?
> >>
> >
> > No, input_allocate_device does kzalloc. Otherwise, this would apply to
> > the other bitmaps as well.
>
> The other bitmaps aren't for switches though. Here's what prompted
> this comment - a snippet from the old (2.6.29) version of
> Documentation/rfkill.txt:
>
> "2. Input device switches (sources of EV_SW events) DO store their current state
> (so you *must* initialize it by issuing a gratuitous input layer event on
> driver start-up and also when resuming from sleep), and that state CAN be
> queried from userspace through IOCTLs."
>

There is a mixup betweeb capabilieies and state bitmasks. In init you
set up the capabilitis bits and you don't need to clear bitmaps. This is
true for everything - keys/buttons, switches, relatixe/absolute axis,
everything.

Now switches do naturally have a certain state. Unlke keys (which are
assumed to be normally in released state) switch can be on or off. So
the driver has (if it can) query the switch state (hardware state) and
issue appropriate input_event() to bring internal state of the device in
sync with the state of the hardware. The same on resume - the switch may
be altered while the box was asleep to upon resume we need to do the
same.

--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3
Prev: tracing: Fix infinite loop in ftrace_update_pid_func()
Next: cpu affinity issue on kvm-88