nput-wacom are the raw hardware
> > values which use a walking bit to indicate where the finger is along
> > the strip. When your finger is at the top of the strip, we report '1';
> > moving down slightly '2', then '4', then '8', and so on until
s
are supported on the same logical port, is necessary to initialize the
tools properly.
Can you consider to merge the patchset into 2.6.38?
Thank you.
Ping
Original Message
Subject:Re: [PATCH 0/2] input: mt: Add EVIOC mechanism for MT slots
Date: Thu, 27 May 2010
uch information through the same
> properties for different surfaces. Thus, we don't need per-axis touch modes.
>
> To push towards a resolution to this issue, Peter, Ping, do you still
> feel we will need per-axis touch modes? If you do, then I could use more
> detail on how such a
a stylus/eraser/mouse or a touch depending
on which tool the strip data are reported with. This idea was
suggested by Dmitry at linux-input mailing list recently. However,
even with this approach, we still need to deal with the strips as an
independent device when no tool is on the tablet for strips to
ine for it?
If we want to merge pen, and other tool types in the future, into the
same MT slot, a way to tell the userland of the different size and
resolution of the tool is a must. Or maybe you have other suggestions
on "pen is implemented as just another contact"?
Ping
and tocuh. If not, we will need to tell
input_mt_report_pointer_emulation if another tool (such as pen) has
already sent pointer events. That is input_mt_report_pointer_emulation
is only called when needed.
Ping
___
xorg-devel@lists.x.org: X.Org developm
t;unified working
surface" for the two opitons above. And I also agree with you that we
should leave the arbitration to the userland for MT events for both
opitons.
But, I think ABS_X/Y arbitration should be considered in the kernel to
reduce the overhead in userland.
Ping
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
class of apps can't really be expected to bind two devices logically
> and mask. So without filtering ABS_X/Y on kernel side, we've
> basically made Bamboo drivers unusable with a range of apps; which
> probably means xf86-input-{evdev|synaptics} (I can't justify adding
>
slot is
another way to address this issue. But that requires MT implementation
and (maybe) spec change.
Thank you for thinking out loud. I am sure you understood why I
haven't picked up that Bamboo for so long ;).
Ping
> To handle this difference, we can scale reported values in driver such
eir own
ways). To me, both one or two logical posts have pros and cons.
Sorry to talk before listening. I am all ears now ;).
Ping
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
I still have one decision to make though:
Do we really want to repeat the pen data with MT_TOOL_PEN? It is
already reported by ST events.
>From my comments for proposal #4, you can tell that I was in favor of
repeating them. After comparing #2 with #4 a bit further, I see both
options have its pros and cons.
Which way should we go? #2 or #4?
Ping
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
ypes of
data are received (#1 only sends pen data).
Which option do you like? We could go with a simple option. But that
would close the door to those feature rich applications.
Ping
Ping
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
On Sun, Nov 7, 2010 at 8:30 AM, Daniel Stone wrote:
>> The existing solution for single touch events is to arbitrate touch
>> when pen is in prox. This is based on the assumption that we do not
>> want to have two cursors competing on the screen.
>
> What do you mean by 'arbitrate' here? I guess y
t pointers
> there is nothing stopping them, either with P&T pen and touch pointers
> or completely unrelated devices.
We'll take care of this step once we know how to report the data.
Ping
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
backward
compatibility support for those clients that don't support MT at all.
Which approach do you like? Or do you have other suggestions share?
Ping
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
On Wed, Sep 22, 2010 at 7:52 PM, Chase Douglas
wrote:
> On Mon, 2010-09-20 at 10:29 -0700, Ping Cheng wrote:
>> On Sun, Sep 19, 2010 at 9:45 PM, Daniel Stone wrote:
>> > Hi all,
>> > This is my second draft of the multitouch proposal, along with a fairly
>> >
On Mon, Sep 20, 2010 at 9:58 PM, Daniel Stone wrote:
> Hi,
>
> On Mon, Sep 20, 2010 at 10:29:49AM -0700, Ping Cheng wrote:
>> On Sun, Sep 19, 2010 at 9:45 PM, Daniel Stone wrote:
>> > This is my second draft of the multitouch proposal, along with a fairly
>> > c
red this case in your
proposal. But I am not familiar with the X server (and evdev) code. So
I am taking a shortcut to get my question answered - asking the expert
:).
Ping
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives
in percent of
>> +the total width of the touchpad. Property: "Synaptics Area"
>
> I believe you meant "total height" in the above line, didn't you?
I guess it is the other way around. AreaLeftEdge/AreaRightEdge has the
"height". Either way, you are
Hi Rafi,
Thank you for the great suggestion. Please let me know if there is
anything in the existing Wacom driver that we can move to the generic
MT support in the server or in evdev. I would love to see an unified
generic MT support in Xorg for all touch devices.
Ping
On Sun, May 9, 2010 at 6
On Mon, Mar 22, 2010 at 5:22 PM, Ping Cheng wrote:
> On Mon, Mar 22, 2010 at 4:57 PM, Henrik Rydberg wrote:
>> Ping Cheng wrote:
>>> 2010/3/20 Ping Cheng :
>>>> I might have mistaken the definition of tracking ID here.
>>>
>>> After reading the Mul
On Mon, Mar 22, 2010 at 4:57 PM, Henrik Rydberg wrote:
> Ping Cheng wrote:
>> 2010/3/20 Ping Cheng :
>>> I might have mistaken the definition of tracking ID here.
>>
>> After reading the Multi-touch (MT) Protocol again, I think combining
>> ABS_MT_TRACKING_I
2010/3/20 Ping Cheng :
> 2010/3/20 Rafi Rubin :
>>>> The reporting is always for the whole group, since the contacts are
>>>> interdependent. I do not see what argument stands because of this, nor the
>>>> rationale behind it. Could you clarify, please?
>&
2010/3/20 Rafi Rubin :
> On 03/20/10 01:58, Ping Cheng wrote:
>> On Fri, Mar 19, 2010 at 3:28 AM, Henrik Rydberg wrote:
>>> Rafi Rubin wrote:
>>>> Of course this doesn't make as much sense if we follow Henrik's argument
>>>> about
>>&
other device specific means. From a device
driver (both kernel and X server) developer's point of view, changing
kernel API now resolves a lot of issues downstream.
Ping
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Hi Rémi,
Thank you for the suggestions. Please see my comments in line.
Ping
On Sun, Feb 14, 2010 at 3:25 PM, Rémi Cardona wrote:
> Le 14/02/2010 22:36, Ping Cheng a écrit :
>> So, my questions are:
>>
>> 1. What is the proper way to retrieve TwinView's display mo
and screen resolutions inside a device driver? Is
there any difference in retrieving those info between RandR 1.2 and
1.3?
Please reply to me no matter you have a full answer, a partial answer,
or even a request for clarification of the question(s).
Ping
__
I still need more suggestions since the problem is still there.
Please share your serial device hacking experience on embedded system
with me if you have any.
Ping
On Wed, Jan 20, 2010 at 7:15 PM, Greg KH wrote:
> On Wed, Jan 20, 2010 at 05:53:43PM -0800, Ping Cheng wrote:
>> This m
n page tells me:
ENOTTY Inapporatriate fd.
What does this mean to me? How do I fix it? Or at least, how do I
trace into the problem.
Any suggestion would be greatly appreciated.
Ping
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/m
ighten it out.
This works for me too. I guess I can also assume that we could ignore just
one device by specifying MatchProduct with product ID, right? All this is
for the next step with udev. Then my question is (sorry I have too many
questions
On Mon, Dec 14, 2009 at 2:59 PM, Ping wrote:
> On Mon, Dec 14, 2009 at 7:36 AM, Dan Nicholson wrote:
>
>> I think it will work the way you envision, but with the caveat that
>> there isn't any parsing of ~/.xorg.conf and never has been. After
>> that, it would work
e
new approach? I hope we have a more "dummy" friendly hotplugging solution
for them. It would also make my job easier.
Thank you, Dan, for your effort no matter where we get :).
Ping
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
bsolute input device by default. If we could allow the input device to tell
us it is a touchscreen device or not, that would great.
I have one comment inline below.
Ping
On Mon, Dec 7, 2009 at 9:05 PM, Dan Nicholson wrote:
> On Mon, Dec 7, 2009 at 6:47 PM, Peter Hutterer
> wrote:
> &g
gical port is for touch and which one is for
penabled.
Now you have the whole picture, I hope :). What would be a valid solution
for my case?
Ping
On Tue, Nov 3, 2009 at 12:03 PM, Greg KH wrote:
> On Tue, Nov 03, 2009 at 02:44:34PM -0500, Adam Jackson wrote:
> > On Tue, 2009-11-03 at 10:
On Tue, Nov 3, 2009 at 3:13 PM, Peter Hutterer wrote:
> On Tue, Nov 03, 2009 at 02:42:03PM -0800, Greg KH wrote:
> > On Tue, Nov 03, 2009 at 02:35:04PM -0800, Ping wrote:
> > > On Tue, Nov 3, 2009 at 2:08 PM, Greg KH wrote:
> > >
> > > > On Tue, Nov 0
On Tue, Nov 3, 2009 at 2:08 PM, Greg KH wrote:
> On Tue, Nov 03, 2009 at 12:19:54PM -0800, Ping wrote:
> > These questions make me feel the kernel driver may need some work.
> Anyway,
> > let me share what I have now before we can figure out a better solution:
> >
someone
show me what parameter(s) I need to use if the ioctl is supported?
Please also reply to me if you know there is no existing way to get the
bInterfaceNumber inside an xorg device driver so I will add my own
workaround in the kernel driver.
Ping
___
xorg
iver?
I need a suggestion/solution. Thank you for your reply.
Ping
On Tue, Nov 3, 2009 at 10:13 AM, Greg KH wrote:
> On Tue, Nov 03, 2009 at 10:03:18AM -0800, Ping wrote:
> > I need a quick answer since searching through the X server code takes too
> > long.
> >
Ok, I 'll take this opportunity to prove xf86-input-wacom is responsive and
give you all a break. I will also take care of both hal/libudev and
xorg.conf. The fix will be ready for xorg 1.8 if my driver can be
included. Fair?
Ping
On Wed, Oct 7, 2009 at 7:14 PM, Daniel Stone wrote:
uot; my driver by creating all devices inside the Init. Then the driver
will cleanup itself in UnInit. I think I like this approach if you guys are
willing to take the risk of Wacom blowing up the server :).
Ping
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
On Wed, Oct 7, 2009 at 4:38 AM, Julien Cristau wrote:
> On Tue, Oct 6, 2009 at 14:07:33 -0700, Ping wrote:
>
> > Does xserver have mechanism to create multiple X input devices in a
> single
> > instance now?
>
> As far as I know, you can check that you're bein
Thank you, Matthew, for picking up this topic for Wacom. Please see my
comments in line.
Ping
On Tue, Oct 6, 2009 at 11:25 AM, Matthew Garrett wrote:
> I think that this will currently break wacom. Wacom is set up to provide
> one input device per input mechanism - so typically we may ha
;m not sure we
>>>> require a C99 compiler yet. I'm not sure that that these tests serve
>>>> any
>>>> real purpose, they can probably just be removed.
>>>>
>>>
>>> Well, they serve a purpose, and I'd like to keep them in for sanity
>>> purposes.
>>>
>>
>> What purpose is that? If these functions were actually called with a
>> NULL PixmapPtr, surely the current code would have crashed with a
>> segmentation fault.
>
>
My experience is "don't change it unless you know it is broken". Gracefully
returning a warning (FALSE) is better than making yourself (xserver) look
bad (crashing).
Ping
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
2009/10/2 Arkadiusz Miskiewicz
> On Friday 02 of October 2009, Ping wrote:
>
> > I think moving drivers into xserver tree benefits both driver and xserver
> > developers as well as distro maintainers.
>
> As distro maintainer I hated monolitic X. It's was nightmare
e
still under the same roof (xorg) but a different room (their own
repository). My concern was I am outside of the building. No one at
xorg cared about if my driver was in sync with the xserver or not. I've
added "tons of" (exaggerated :) #ifdefs to c
ejected with a reason. Regression testing is done
for all x.org release candidates. The coding and testing work don't have to
be directly done by the maintainers. It is the same as managers
don't really do the realy work :). You just need to make sure someone you
trust has done the job. Finding the ones that you can trust is definitely
the maintainer's responsibility.
Ping
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Well, we may have a surprise for you someday on OpenSolaris. As far as I
know, linuxwacom has been running on FreeBSD for a while (
http://www.freshports.org/x11-drivers/input-wacom). Maybe you can help us
deploy it on other *BSDs. Let me know if you don't have a Wacom tablet to
play with.
wait until we got all the permissions from previous developers, which
would take sometime. Is it possible for me to expose the GPL'd code at
freedesktop.org/git/xorg before we get the permissions?
Thank you,
Ping
___
xorg-devel mailing list
xorg-
48 matches
Mail list logo
