lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimRGdMvpqFz+ZNDE+Jn4Kpi-ta+wKt760_Y93kA@mail.gmail.com>
Date:	Wed, 24 Nov 2010 09:46:48 -0800
From:	Ping Cheng <pinglinux@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	linux-kernel@...r.kernel.org, jkosina@...e.cz
Subject: Re: [PATCH] Add BTN_TOOL_BUTTONS to input.h

On Tue, Nov 23, 2010 at 6:44 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
>
>> >>> That is exactly what I am trying to convince you. Without being able
>> >>> to tell one button event from the other, even just logically, how can
>> >>> I and other clients remap them?
>> >>
>> >> EVIOCSKEYCODE. You just need to wire wacom driver to support this ioctl.
>>
>> Hold on. I was too concentrated on the buttons then. There are touch
>> rings (reported as ABS_WHEEL) on the tablet. How do we pass the raw
>> ring data to the user land and tell if that ABS_WHEEL is from the ring
>> or from a stylus' wheel? Should we add an ABS_RING then?
>
> May be. Could you please describe exactly what it is?

Take a look at this page: http://www.wacom.com/intuos/. The ring is
the one on the center of the left edge. We also have two strips on
both edges of some tablets:
http://www.wacom.com/cintiq/cintiq-12wx.php. I was not suggesting to
add ABS_RING. Actually, adding ABS_RING is overkilling since we may
add other stuff on the tablet which would require a new ABS_something.
One BTN_TOOL_ groups everything on the tablet, which is much cleaner
than adding more ABS_*.

> What is the default application? Is it really used for scrolling the work area up
> and down?

It can be used for scrolling, zooming, or any application specific
functions. For example, it can be translated into some painting
effect, such shadowing, dimming....

>> Also, if there is no tool on the tablet, which BTN_TOOL_* should we
>> use to report those buttons and strips/rings? They are not PEN, not
>> MOUSE, and not TOUCH. They are in fact an independent tool, like it or
>> not.
>
> No, the buttons on the device are not independent tool but rather fixed
> features that are applicable to all tools and none in particular.

Which tool do you think we can use while no tool is on the tablet? No
matter which one we use, it is confusing. The
strips/ring/wheel/buttons on the tablet do not belong to those tools
at all. They live without any of those tools.

Plus, we are not just talking about buttons here. I started the
argument with buttons and Bamboo since it is the first one that
introduced the BTN_TOOL_FINGER in a different meaning. The need of
BTN_TOOL_BUUTONS is not really for Bamboo. It is for the strips and
rings on the Intuos and Cintiq (see the URL I refered above).

> Considering that proper use of input protocol means that you describe
> _entire_ state of the device how would BTN_TOOL_BUTTONS help you do that
> if button is presses on both touchpad and mouse?

There should be no confusion between pressing a button on a touchpad
or a mouse from a driver's perspective. The driver should be able to
tell user land which button has been pressed/released. It is up to the
user to decide which function they want to assign to the button.

We assign default values to the buttons just to be friendly to most
common apps/users. But, we should not limit user land usability.
Reporting raw strips/ring/wheel vaules gives the room for client to
develop their own functions. But those raw data do not belong to any
of the other tools.

> What about pressed on
> the tablet and released on mouse? Note that there should be no
> ordering dependencies; userspace is expected to accumulate all data and
> maybe cancel out opposites until it gets EV_SYN/SYN_REPORT.
>
> I was thinking that while having pen and thouch as separate devices
> might not be the best idea having mouse and maybe lens as separate
> input devices might make more sense. I'll try to find some time and
> play with my Graphire...

Yeah, Graphire may prove my point. Do you have a Graphire 4? How are
you going to pass the REL_WHEEL event on the tablet while a mouse,
which also has a REL_WHEEL, is on the tablet?

We are complicating a simple problem/request here.

Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ