On Thu, Sep 29, 2011 at 08:04:00AM +0200, Eduard Hasenleithner wrote:
> 2011/9/29 Peter Hutterer :
> >> Ah, finally I understand the whole picture which Ping wanted me (us)
> >> to tell. I see it similar. When looking at the 4 leds, I'm seeing
> >> something like a software settable "rotary selecti
2011/9/29 Peter Hutterer :
>> Ah, finally I understand the whole picture which Ping wanted me (us)
>> to tell. I see it similar. When looking at the 4 leds, I'm seeing
>> something like a software settable "rotary selection switch".
>> Applications want to be informed immediately when the value cha
This is a heads-up, a brain storming and ideas collection all at the
same time.
xsetwacom is the previously small utility to tweak random driver functions.
This is what this tool should remain as. I'm happy to add any new driver
feature but I don't want semantic patches to filter into xsetwacom. I
On Wed, Sep 28, 2011 at 11:29:39PM +0200, Eduard Hasenleithner wrote:
> Here is some further thought about the pixmap handling. What I somehow
> dislike is the "dirty" handling of pixmaps when the client is closed.
> How about pre-allocating the pixmaps at driver startup:
>
> void wcmLedInitPixmap
On Wed, Sep 28, 2011 at 06:28:39PM -0700, Ping Cheng wrote:
> On Wed, Sep 28, 2011 at 4:02 PM, Peter Hutterer
> wrot
> >> We can make the "xsetwacom led" a get and set command (instead of
> >> get-only). If end users can set led status, the following may happen:
> >> one user/app may change the s
On Wed, Sep 28, 2011 at 4:02 PM, Peter Hutterer wrot
>> We can make the "xsetwacom led" a get and set command (instead of
>> get-only). If end users can set led status, the following may happen:
>> one user/app may change the status while the other wants it unchanged.
>> How do we avoid this kind
On Wed, Sep 28, 2011 at 08:36:47PM +0200, Eduard Hasenleithner wrote:
> Hi
>
> 2011/9/28 Ping Cheng :
> > On Wed, Sep 28, 2011 at 4:10 AM, Peter Hutterer
> > wrote:
> >> sorry, I'm just going to reply to this message here instead of each of them
> >> in the thread because otherwise my answers wou
On Wed, Sep 28, 2011 at 11:05:35AM -0700, Ping Cheng wrote:
> On Wed, Sep 28, 2011 at 4:10 AM, Peter Hutterer
> wrote:
> > sorry, I'm just going to reply to this message here instead of each of them
> > in the thread because otherwise my answers would be too split up. Also, I'm
> > a bit confused
Here is some further thought about the pixmap handling. What I somehow
dislike is the "dirty" handling of pixmaps when the client is closed.
How about pre-allocating the pixmaps at driver startup:
void wcmLedInitPixmap(WacomDevicePtr priv, int *values, int count)
{
int i;
ScreenPtr
Hi
2011/9/28 Ping Cheng :
> On Wed, Sep 28, 2011 at 4:10 AM, Peter Hutterer
> wrote:
>> sorry, I'm just going to reply to this message here instead of each of them
>> in the thread because otherwise my answers would be too split up. Also, I'm
>> a bit confused because some of the msgs in this thr
On Wed, Sep 28, 2011 at 4:10 AM, Peter Hutterer
wrote:
> sorry, I'm just going to reply to this message here instead of each of them
> in the thread because otherwise my answers would be too split up. Also, I'm
> a bit confused because some of the msgs in this thread seem contradictory.
>
> One im
Dnia 2011-09-27, wto o godzinie 11:56 +0200, Eduard Hasenleithner pisze:
[..]
> First, I don't know. The windows driver (AFAIR) allows to set it, and
> it is provided by the kernel module. Second, we have actually three
> luminances:
> 1) OLED matrix display luminance
> 2) luminance of status led w
sorry, I'm just going to reply to this message here instead of each of them
in the thread because otherwise my answers would be too split up. Also, I'm
a bit confused because some of the msgs in this thread seem contradictory.
One important thing that I want to point out: xf86-input-wacom is an X
13 matches
Mail list logo
