Prev: drivers/scsi: Use memdup_user
Next: [PATCH -mm 0/1] (Was: ptrace: unify FDPIC implementations)
From: Chase Douglas on 22 May 2010 10:50
On Sat, 2010-05-22 at 12:38 +0200, Henrik Rydberg wrote:
> Getting serious, it is anyone's guess what will happen next, but I was picturing
> a table, with a large multitouch screen and buttons along the side of the table.
> Sure, we can do "ABS_BTN_0", "ABS_BTN_1", etc, but with slots in place, it seems
> more natural to use something like "ABS_MT_BTN_X". While at it, REL_MT event
> makes sense for those touchscreen techniques which register changes, like
> acoustic pulse recognition.

Shouldn't this be handled in userspace? I don't think we want to be
quirking drivers for instances where the same touchscreen is overlaid on
buttons in some cases, but not in others. If we don't quirk, we'd need
some mechanism to tell the driver about such buttons.

-- Chase

--
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/
From: Chase Douglas on 22 May 2010 17:00
On Sat, 2010-05-22 at 19:47 +0200, Henrik Rydberg wrote:
> Chase Douglas wrote:
> > On Sat, 2010-05-22 at 12:38 +0200, Henrik Rydberg wrote:
> >> Getting serious, it is anyone's guess what will happen next, but I was picturing
> >> a table, with a large multitouch screen and buttons along the side of the table.
> >> Sure, we can do "ABS_BTN_0", "ABS_BTN_1", etc, but with slots in place, it seems
> >> more natural to use something like "ABS_MT_BTN_X". While at it, REL_MT event
> >> makes sense for those touchscreen techniques which register changes, like
> >> acoustic pulse recognition.
>
> s/ABS/KEY/
>
> >
> > Shouldn't this be handled in userspace? I don't think we want to be
> > quirking drivers for instances where the same touchscreen is overlaid on
> > buttons in some cases, but not in others. If we don't quirk, we'd need
> > some mechanism to tell the driver about such buttons.
>
> Perhaps you would like to clarify what "this" means here, and how you arrive at
> quirking drivers.

I'm arriving rather late to the conversation, so this could be a matter
of me not understanding everything. What I thought you were proposing is
something like what I have on my Nexus One: an MT area encompassing a
touchscreen and extending to an area of four "buttons" off the bottom of
the screen. I was thinking that interactions with these buttons would
trigger the KEY_MT_BTN events you mentioned. However, if thats the case
then the driver needs to know of these buttons, so we've gone from a
dumb touchscreen driver to a driver that must be aware of regions of the
screen where there are buttons. This is where I think it would be better
to have a userspace application (X?) understand the properties of the
screen to know exactly what a touch means, instead of trying to
interpret it inside the kernel.

If this isn't what you meant, then feel free to ignore me :).

-- Chase

--
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/
 | 
Pages: 1
Prev: drivers/scsi: Use memdup_user
Next: [PATCH -mm 0/1] (Was: ptrace: unify FDPIC implementations)