[PATCH] x11proto: add permille, ezh, and EZH to keysymdef.h
Hi, as requested in https://bugs.freedesktop.org/show_bug.cgi?id=19687 I'm submitting a patch for review to add the following mnemonic symbols: XK_permille for U+2030 PER MILLE SIGN XK_EZH for U+01B7 LATIN CAPITAL LETTER EZH XK_ezh for U+0292 LATIN SMALL LETTER EZH These are the last mnemonic symbols missing from the Finnish keyboard layout. The characters are part of the Finnish standard, ezh is used in Sami and permille sign is used commonly in Finland, probably in other countries as well. Cheers, -- Marko Myllynen >From fdf64362dbe22144d905d9b7716d0158bcf308ab Mon Sep 17 00:00:00 2001 From: Marko Myllynen Date: Tue, 4 Oct 2011 10:06:05 +0300 Subject: [PATCH] x11proto: add permille, ezh, and EZH to keysymdef.h This patch adds the following mnemonic symbols: XK_permille for U+2030 PER MILLE SIGN XK_EZH for U+01B7 LATIN CAPITAL LETTER EZH XK_ezh for U+0292 LATIN SMALL LETTER EZH These are the last mnemonic symbols missing from the Finnish keyboard layout. The characters are part of the Finnish standard, ezh is used in Sami and permille sign is used commonly in Finland, probably in other countries as well. https://bugs.freedesktop.org/show_bug.cgi?id=19687 --- keysymdef.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/keysymdef.h b/keysymdef.h index f96bc09..38b6115 100644 --- a/keysymdef.h +++ b/keysymdef.h @@ -1467,6 +1467,7 @@ SOFTWARE. #define XK_leftdoublequotemark 0x0ad2 /* U+201C LEFT DOUBLE QUOTATION MARK */ #define XK_rightdoublequotemark 0x0ad3 /* U+201D RIGHT DOUBLE QUOTATION MARK */ #define XK_prescription 0x0ad4 /* U+211E PRESCRIPTION TAKE */ +#define XK_permille 0x0ad5 /* U+2030 PER MILLE SIGN */ #define XK_minutes 0x0ad6 /* U+2032 PRIME */ #define XK_seconds 0x0ad7 /* U+2033 DOUBLE PRIME */ #define XK_latincross0x0ad9 /* U+271D LATIN CROSS */ @@ -1970,6 +1971,8 @@ SOFTWARE. #define XK_obarred0x1000275 /* U+0275 LATIN SMALL LETTER BARRED O */ #define XK_SCHWA 0x100018f /* U+018F LATIN CAPITAL LETTER SCHWA */ #define XK_schwa 0x1000259 /* U+0259 LATIN SMALL LETTER SCHWA */ +#define XK_EZH0x10001b7 /* U+01B7 LATIN CAPITAL LETTER EZH */ +#define XK_ezh0x1000292 /* U+0292 LATIN SMALL LETTER EZH */ /* those are not really Caucasus */ /* For Inupiak */ #define XK_Lbelowdot 0x1001e36 /* U+1E36 LATIN CAPITAL LETTER L WITH DOT BELOW */ -- 1.7.1 ___ 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
Re: [PATCH] fix doPolyText use-after-free issue
Attached.
Thanks Jeremy. What's happening to the 1.10.x branch now ? Can this be
nominated for that too ?
Alan.
On 09/28/11 07:46, Jeremy Huddleston wrote:
> I missed this point at first. The context is that in 'bail', c is accessed
> and expected to be the old value.
>
> Candidate for 1.11-branch
>
> Reviewed-by: Jeremy Huddleston
>
> I think something is wrong with your mailer (or maybe mine). I was unable to
> git-am this patch. Can you please resend it as an attachment, and I'll
> git-am it into my tree.
>
> --Jeremy
>
> On Sep 27, 2011, at 6:51 AM, Alan Hourihane wrote:
>
>> dixfonts: Don't overwrite local c variable until new_closure is safely
>> initialized.
>>
>> Signed-off-by: Alan Hourihane
>>
>> diff --git a/dix/dixfonts.c b/dix/dixfonts.c
>> index fbac124..d2bcb84 100644
>> --- a/dix/dixfonts.c
>> +++ b/dix/dixfonts.c
>> @@ -1302,31 +1302,30 @@ doPolyText(ClientPtr client, PTclosurePtr c)
>> goto bail;
>> }
>> *new_closure = *c;
>> -c = new_closure;
>>
>> -len = c->endReq - c->pElt;
>> -c->data = malloc(len);
>> -if (!c->data)
>> +len = new_closure->endReq - new_closure->pElt;
>> +new_closure->data = malloc(len);
>> +if (!new_closure->data)
>> {
>> -free(c);
>> +free(new_closure);
>> err = BadAlloc;
>> goto bail;
>> }
>> -memmove(c->data, c->pElt, len);
>> -c->pElt = c->data;
>> -c->endReq = c->pElt + len;
>> +memmove(new_closure->data, new_closure->pElt, len);
>> +new_closure->pElt = new_closure->data;
>> +new_closure->endReq = new_closure->pElt + len;
>>
>> /* Step 2 */
>>
>> -pGC = GetScratchGC(c->pGC->depth, c->pGC->pScreen);
>> +pGC = GetScratchGC(new_closure->pGC->depth,
>> new_closure->pGC->pScreen);
>> if (!pGC)
>> {
>> -free(c->data);
>> -free(c);
>> +free(new_closure->data);
>> +free(new_closure);
>> err = BadAlloc;
>> goto bail;
>> }
>> -if ((err = CopyGC(c->pGC, pGC, GCFunction |
>> +if ((err = CopyGC(new_closure->pGC, pGC, GCFunction |
>> GCPlaneMask | GCForeground |
>> GCBackground | GCFillStyle |
>> GCTile | GCStipple |
>> @@ -1337,15 +1336,16 @@ doPolyText(ClientPtr client, PTclosurePtr c)
>> Success)
>> {
>> FreeScratchGC(pGC);
>> -free(c->data);
>> -free(c);
>> +free(new_closure->data);
>> +free(new_closure);
>> err = BadAlloc;
>> goto bail;
>> }
>> +c = new_closure;
>> origGC = c->pGC;
>> c->pGC = pGC;
>> ValidateGC(c->pDraw, c->pGC);
>> -
>> +
>> ClientSleep(client, (ClientSleepProcPtr)doPolyText, c);
>>
>> /* Set up to perform steps 3 and 4 */
>>
>> ___
>> 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
>>
commit cc3981b3a6d2a496afd54d18656730bdf88d221c
Author: Alan Hourihane
Date: Tue Sep 27 14:45:48 2011 +0100
dixfonts: Don't overwrite local c variable until new_closure is safely
initialized.
diff --git a/dix/dixfonts.c b/dix/dixfonts.c
index fbac124..d2bcb84 100644
--- a/dix/dixfonts.c
+++ b/dix/dixfonts.c
@@ -1302,31 +1302,30 @@ doPolyText(ClientPtr client, PTclosurePtr c)
goto bail;
}
*new_closure = *c;
- c = new_closure;
- len = c->endReq - c->pElt;
- c->data = malloc(len);
- if (!c->data)
+ len = new_closure->endReq - new_closure->pElt;
+ new_closure->data = malloc(len);
+ if (!new_closure->data)
{
- free(c);
+ free(new_closure);
err = BadAlloc;
goto bail;
}
- memmove(c->data, c->pElt, len);
- c->pElt = c->data;
- c->endReq = c->pElt + len;
+ memmove(new_closure->data, new_closure->pElt, len);
+ new_closure->pElt = new_closure->data;
+ new_closure->endReq = new_closure->pElt + len;
/* Step 2 */
- pGC = GetScratchGC(c->pGC->depth, c->pGC->pScreen);
+ pGC = GetScratchGC(new_closure->pGC->depth, new_closure->pGC->pScreen);
if (!pGC)
{
- free(c->data);
- free(c);
+ free(new_closure->data);
+ free(new_closure);
err = BadAlloc;
goto bail;
}
- if ((err = CopyGC(c->pGC, pGC, GCFunction |
+ if ((err = CopyGC(new_closure->pGC, pGC, GCFunction |
GCPlaneMask | GCForeground |
GCBackground | GCFillStyle |
GCTile | GCStipple |
@@ -1337,15 +1336,16 @@ doPolyText(ClientPtr client, PTclosurePtr c)
Su
Re: [PATCH xserver 3/3] record: Preserve client input buffer for RecordEnableContext request.
On 10/03/2011 06:03 PM, Keith Packard wrote: On Mon, 3 Oct 2011 15:16:27 +0300, Rami Ylimäki wrote: This request installs hooks that keep sending replies even after the request handler has finished. Each reply accesses the input buffer. If we let the buffer to be shared, we will eventually read garbage or even from freed memory. Would it be possible to simply store any necessary data locally, instead of hacking up the OS layer to store it for us? It should be possible, but I think that the current approach is the simplest way to solve the problem. I'll present some alternatives below that occurred to me when fixing the problem. A client might start recording replies without selecting any requests for recording. This means that the Record extension would have to track and cache requests of all clients even though the requests themselves wouldn't be recorded. Caching would need to be done for all clients, instead of just recorded clients, because we wouldn't know in advance whether replies to problematic requests, such as RecordEnableContext, would be recorded later on. Saving the op-codes of latest requests could be done in a couple of ways: 1. Add op-code fields into the ClientRec structure and update them in Dispatch/ReadRequestFromClient just like ClientRec::requestBuffer is updated. 2. Track client destruction and creation with ClientStateCallback and wrap the client request vector for all clients in Record extension. This would allow the the latest request op-codes to be saved into a client private structure of Record extension, where it could be fetched when a reply is recorded. Any preferences? I guess option 2 is the most local way to fix the problem, but also requires more code lines than the other approaches. -- Rami ___ 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
[PATCH v2 xserver] record: Prevent out of bounds access when recording a reply.
Any pad bytes in replies are written to the client from a zeroed
array. However, record extension tries to incorrectly access the pad
bytes from the end of reply data.
Signed-off-by: Rami Ylimäki
Reviewed-by: Erkki Seppälä
---
v1: Fixed the issue when a reply was cached into a recording context buffer.
v2: Fixes the issue also for large replies that don't fit into the cache.
include/os.h|3 ++-
os/io.c |1 +
record/record.c | 53 ++---
3 files changed, 33 insertions(+), 24 deletions(-)
diff --git a/include/os.h b/include/os.h
index 5401ea4..fda0181 100644
--- a/include/os.h
+++ b/include/os.h
@@ -451,9 +451,10 @@ extern _X_EXPORT CallbackListPtr ReplyCallback;
typedef struct {
ClientPtr client;
const void *replyData;
-unsigned long dataLenBytes;
+unsigned long dataLenBytes; /* actual bytes from replyData + pad bytes */
unsigned long bytesRemaining;
Bool startOfReply;
+unsigned long padBytes; /* pad bytes from zeroed array */
} ReplyInfoRec;
/* stuff for FlushCallback */
diff --git a/os/io.c b/os/io.c
index 068f5f0..955bf8b 100644
--- a/os/io.c
+++ b/os/io.c
@@ -809,6 +809,7 @@ WriteToClient (ClientPtr who, int count, const void *__buf)
replyinfo.client = who;
replyinfo.replyData = buf;
replyinfo.dataLenBytes = count + padBytes;
+ replyinfo.padBytes = padBytes;
if (who->replyBytesRemaining)
{ /* still sending data of an earlier reply */
who->replyBytesRemaining -= count + padBytes;
diff --git a/record/record.c b/record/record.c
index 68311ac..db77b64 100644
--- a/record/record.c
+++ b/record/record.c
@@ -269,8 +269,9 @@ RecordFlushReplyBuffer(
* device events and EndOfData, pClient is NULL.
* category is the category of the protocol element, as defined
* by the RECORD spec.
- * data is a pointer to the protocol data, and datalen is its length
- * in bytes.
+ * data is a pointer to the protocol data, and datalen - padlen
+ * is its length in bytes.
+ * padlen is the number of pad bytes from a zeroed array.
* futurelen is the number of bytes that will be sent in subsequent
* calls to this function to complete this protocol element.
* In those subsequent calls, futurelen will be -1 to indicate
@@ -290,7 +291,7 @@ RecordFlushReplyBuffer(
*/
static void
RecordAProtocolElement(RecordContextPtr pContext, ClientPtr pClient,
- int category, pointer data, int datalen, int futurelen)
+ int category, pointer data, int datalen, int padlen, int
futurelen)
{
CARD32 elemHeaderData[2];
int numElemHeaders = 0;
@@ -398,15 +399,20 @@ RecordAProtocolElement(RecordContextPtr pContext,
ClientPtr pClient,
}
if (datalen)
{
+ static char padBuffer[3]; /* as in FlushClient */
memcpy(pContext->replyBuffer + pContext->numBufBytes,
- data, datalen);
- pContext->numBufBytes += datalen;
+ data, datalen - padlen);
+ pContext->numBufBytes += datalen - padlen;
+ memcpy(pContext->replyBuffer + pContext->numBufBytes,
+ padBuffer, padlen);
+ pContext->numBufBytes += padlen;
}
}
else
+{
RecordFlushReplyBuffer(pContext, (pointer)elemHeaderData,
- numElemHeaders, (pointer)data, datalen);
-
+ numElemHeaders, (pointer)data, datalen - padlen);
+}
} /* RecordAProtocolElement */
@@ -483,19 +489,19 @@ RecordABigRequest(RecordContextPtr pContext, ClientPtr
client, xReq *stuff)
/* record the request header */
bytesLeft = client->req_len << 2;
RecordAProtocolElement(pContext, client, XRecordFromClient,
- (pointer)stuff, SIZEOF(xReq), bytesLeft);
+ (pointer)stuff, SIZEOF(xReq), 0, bytesLeft);
/* reinsert the extended length field that was squished out */
bigLength = client->req_len + bytes_to_int32(sizeof(bigLength));
if (client->swapped)
swapl(&bigLength);
RecordAProtocolElement(pContext, client, XRecordFromClient,
- (pointer)&bigLength, sizeof(bigLength), /* continuation */ -1);
+ (pointer)&bigLength, sizeof(bigLength), 0, /* continuation */
-1);
bytesLeft -= sizeof(bigLength);
/* record the rest of the request after the length */
RecordAProtocolElement(pContext, client, XRecordFromClient,
- (pointer)(stuff + 1), bytesLeft, /* continuation */ -1);
+ (pointer)(stuff + 1), bytesLeft, 0, /* continuation */ -1);
} /* RecordABigRequest */
@@ -542,7 +548,7 @@ RecordARequest(ClientPtr client)
RecordABigRequest(pContext, client, stuff);
else
RecordAProtocolElement(pContext, client, XRecordFromClient,
-
Re: [PATCH 0/3] simplify pixmap create/free hooks
On Sat, 1 Oct 2011 23:08:45 -0700, Jamey Sharp wrote: > During last year's XDS, I started an experiment to see if resource > allocation and freeing could lose the horrible wrap/unwrap boilerplate. > As I recall, I got the idea from something keithp said: Create and Free > hooks could be implemented with callbacks.h instead. > > I didn't finish that experiment, but I think these patches are > improvements regardless, and they nicely pave the way for further > cleanups if somebody gets around to it. > > The following changes since commit e45a5c9dcf77fc61bfed055f7d7a437741d07315: > > Make GC clientClip always be a region. (2011-09-28 13:27:04 -0700) > > are available in the git repository at: > git://anongit.freedesktop.org/~jamey/xserver pixmap-hooks > > Jamey Sharp (3): > Have FreePixmap call screen hooks, not the other way around. > Introduce CreatePixmap, allocating a header and calling screen hooks. > Move pixmap size limit checking to CreatePixmap, from screen hooks. Where's the ABI bump for out-of-tree drivers? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ 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
Re: [PULL] XI 2.1 - raw events and smooth scrolling
Hi,
On 3 October 2011 11:50, Max Schwarz wrote:
>> Input: Add smooth-scrolling support to GetPointerEvents
> There's a subtle bug on that one: Old-style scroll button presses create
> inverted emulated presses (and maybe inverted valuator events, but I don't
> know which direction is 'up' or 'down' on the valuator).
Good catch, thanks! Up is negative in the valuators, so this:
> Take a look at dix/getevents.c, GetPointerEvents():
>
>> switch(buttons) {
>> case 4:
>> adj = 1.0;
>> [snip]
>> }
should be -1.0. Care to send a patch with git-format-patch?
Cheers,
Daniel
___
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
Re: [PATCH 00/12] Multihead screen crossing fixes
Hi, On 4 October 2011 06:23, Peter Hutterer wrote: > This is another attempt at the screen crossing fixes that I sent out last > month. The basic goal was to make switching between ScreenRecs work for > absolute devices. Which turned out tricky and the best solution I came up > with was to unify multiscreen pointer behaviour between RandR and Xinerama - > an absolute device is now mapped to the total area across all screens. > > Patches 01-06 are general cleanup and documentation fixes, the fun starts at > 07. For the true connoisseur of insanity I recommend 12/12, the comment > before fill_pointer_events is worth reading. I'm sure you'll be laughing > until bedtime at the necessity of juggling 5 different coordinate systems > between devices, pointer placement and protocol events. > (That's the simplest solution I could come up with, everything else I tried > I ran into a wall.) For patches 1-11: Reviewed-by: Daniel Stone although returning a screen from miPointerSetPosition seems a bit weird. Oh well. I'm not sure I'm feeling up to 12 right now, as I just ate breakfast. Cheers, Daniel ___ 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
[PATCH] [xorg/xserver] os/connection: Prevent WaitForSomething from busylooping
CheckConnections didn't check for write blocked clients. If an ignored client is write-blocked but then closed, the Select in WaitForSomething will return EBADF. CheckConnections is supposed to weed these connections out but it doesn't, because it checks only for AllClients, and ignored clients (which can still be written to) aren't in that set. This patch makes CheckConnections check also the set ClientsWriteBlocked in addition to AllClients. Test case: run cnee, put it in suspend with ^Z and generate a lot of events, so that its connection becomes write blocked. Now kill -9 the process and witness X entering a neverending loop. Cnee's connection issues RecordEnableContext, which makes the connection ignored. Signed-off-by: Erkki Seppälä Reviewed-by: Rami Ylimäki --- os/connection.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/os/connection.c b/os/connection.c index 1d38906..07021e7 100644 --- a/os/connection.c +++ b/os/connection.c @@ -993,7 +993,7 @@ CheckConnections(void) #ifndef WIN32 for (i=0; ihttp://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Maintaining backwards compatibility with swap macros
Hello, is this by any chance related to the swap macro changes? ../../Xext/xselinux_ext.c: In function ‘SELinuxSendItemsToClient’: ../../Xext/xselinux_ext.c:340:16: warning: unused variable ‘n’ [-Wunused-variable] In function ‘SProcSELinuxQueryVersion’, inlined from ‘SProcSELinuxDispatch’ at ../../Xext/xselinux_ext.c:628:2: ../../Xext/xselinux_ext.c:532:5: error: call to ‘wrong_size’ declared with attribute error: wrong sized variable passed to swap ../../Xext/xselinux_ext.c:533:5: error: call to ‘wrong_size’ declared with attribute error: wrong sized variable passed to swap Thanks Michal ___ 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
Re: Maintaining backwards compatibility with swap macros
On Tue, Oct 4, 2011 at 9:24 AM, Michal Suchanek wrote:
> Hello,
>
> is this by any chance related to the swap macro changes?
>
> ../../Xext/xselinux_ext.c: In function ‘SELinuxSendItemsToClient’:
> ../../Xext/xselinux_ext.c:340:16: warning: unused variable ‘n’
> [-Wunused-variable]
> In function ‘SProcSELinuxQueryVersion’,
> inlined from ‘SProcSELinuxDispatch’ at ../../Xext/xselinux_ext.c:628:2:
> ../../Xext/xselinux_ext.c:532:5: error: call to ‘wrong_size’ declared
> with attribute error: wrong sized variable passed to swap
> ../../Xext/xselinux_ext.c:533:5: error: call to ‘wrong_size’ declared
> with attribute error: wrong sized variable passed to swap
>
> Thanks
>
> Michal
Yes, and those are the kinds of errors we like seeing, because they've
existed for a long time but are just now being exposed.
I think the attached patch should fix it up. client_major/minor are
CARD8s, so swapping them just destroys their values.
Give your Tested-by/Reviewed-by and we'll get it committed.
Thanks,
Matt
From e0628cee60f9de96f4f229bc9e618113c532251c Mon Sep 17 00:00:00 2001
From: Matt Turner
Date: Tue, 4 Oct 2011 10:01:50 -0400
Subject: [PATCH] Fix xselinux after swap change
Signed-off-by: Matt Turner
---
Xext/xselinux_ext.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/Xext/xselinux_ext.c b/Xext/xselinux_ext.c
index 56f2d1f..246b05b 100644
--- a/Xext/xselinux_ext.c
+++ b/Xext/xselinux_ext.c
@@ -337,7 +337,7 @@ static int
SELinuxSendItemsToClient(ClientPtr client, SELinuxListItemRec *items,
int size, int count)
{
-int rc, k, n, pos = 0;
+int rc, k, pos = 0;
SELinuxListItemsReply rep;
CARD32 *buf;
@@ -529,8 +529,6 @@ SProcSELinuxQueryVersion(ClientPtr client)
REQUEST(SELinuxQueryVersionReq);
REQUEST_SIZE_MATCH(SELinuxQueryVersionReq);
-swaps(&stuff->client_major);
-swaps(&stuff->client_minor);
return ProcSELinuxQueryVersion(client);
}
--
1.7.3.4
___
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
Re: [PATCH 12/12] input: change pointer screen crossing behaviour for multiple ScreenRecs
Hello, The X server off two-screen-coordinates branch builds and runs in two-csreen configuration with a mouse. However, the XI tests shipped with the X server fail. Worse, they crash. Thanks Michal ___ 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
Re: [PULL] prep work for screen crossing fixes
On 4 October 2011 07:58, Jamey Sharp wrote: > On Tue, Oct 04, 2011 at 03:35:41PM +1000, Peter Hutterer wrote: >> On Mon, Oct 03, 2011 at 10:02:28PM -0700, Jamey Sharp wrote: >> > On Tue, Oct 04, 2011 at 02:15:53PM +1000, Peter Hutterer wrote: >> > > On Mon, Oct 03, 2011 at 09:02:19PM -0700, Keith Packard wrote: >> > > > On Tue, 4 Oct 2011 13:26:35 +1000, Peter Hutterer >> > > > wrote: >> > > > > Store desktop dimensions in screenInfo. >> > > > >> > > > Do we need the minimum x/y of the desktop too? >> > > >> > > is it ever other than 0/0? >> > >> > Sure, that's legal (though crazy). Besides the xorg.conf ServerLayout >> > syntax for positioning a Screen "RightOf", "Below", etc, you can also >> > set the screen's absolute position. >> >> right, that's for a single screen. but can the desktop origin ever be >> non-zero? Can you have layout where the first screen goes from say -1024..0 >> and the second from 0..1204? If you do that with xrandr it shifts everything to make the leftmost/topmost screen start at 0. At least it used to. It's not something that should be relied on too much, though, I guess. There were already people complaining that this shifting breaks their screen layout (eg. when one screen is turned off temporarily or added to existing layout, or changes resolution). > > I believe that could happen in this kind of config, for example: > > Screen "screen1" -1024 0 > Screen "screen2" RightOf "screen1" > > I think it might also happen if you did: > > Screen "screen1" > Screen "screen2" LeftOf "screen1" > > I also don't think there's anything forcing screens to be contiguous. In > general I believe the config parser gives you plenty of rope to shoot > yourself in the foot. Definitely. Some people are placing their screens some dozens of pixels apart to account for the screen borders and make the cursor motion "logical". It's hard to do because you can't rely on --left-of or such but should be possible. Thanks Michal ___ 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
Re: [PATCH 0/3] simplify pixmap create/free hooks
On Tue, Oct 04, 2011 at 10:41:48AM +0100, Chris Wilson wrote: > On Sat, 1 Oct 2011 23:08:45 -0700, Jamey Sharp wrote: > > Jamey Sharp (3): > > Have FreePixmap call screen hooks, not the other way around. > > Introduce CreatePixmap, allocating a header and calling screen hooks. > > Move pixmap size limit checking to CreatePixmap, from screen hooks. > > Where's the ABI bump for out-of-tree drivers? Are we doing that for every change now? There's already an ABI bump in somebody's pull request for 1.12. I forget whether it got merged yet. Jamey signature.asc Description: Digital signature ___ 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
Re: Maintaining backwards compatibility with swap macros
On 4 October 2011 16:02, Matt Turner wrote: > On Tue, Oct 4, 2011 at 9:24 AM, Michal Suchanek wrote: >> Hello, >> >> is this by any chance related to the swap macro changes? >> >> ../../Xext/xselinux_ext.c: In function ‘SELinuxSendItemsToClient’: >> ../../Xext/xselinux_ext.c:340:16: warning: unused variable ‘n’ >> [-Wunused-variable] >> In function ‘SProcSELinuxQueryVersion’, >> inlined from ‘SProcSELinuxDispatch’ at ../../Xext/xselinux_ext.c:628:2: >> ../../Xext/xselinux_ext.c:532:5: error: call to ‘wrong_size’ declared >> with attribute error: wrong sized variable passed to swap >> ../../Xext/xselinux_ext.c:533:5: error: call to ‘wrong_size’ declared >> with attribute error: wrong sized variable passed to swap >> >> Thanks >> >> Michal > > Yes, and those are the kinds of errors we like seeing, because they've > existed for a long time but are just now being exposed. > > I think the attached patch should fix it up. client_major/minor are > CARD8s, so swapping them just destroys their values. > > Give your Tested-by/Reviewed-by and we'll get it committed. All I can say is that the X server builds with the patch applied even with xselinux enabled but I don't use the extension. BTW it adds a warning about stuff variable being unused - probably defined in one of the macros. Thanks Michal ___ 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
Re: Maintaining backwards compatibility with swap macros
On Tue, Oct 4, 2011 at 2:33 PM, Michal Suchanek wrote: > BTW it adds a warning about stuff variable being unused - probably > defined in one of the macros. It's because the swap macros stopped taking a second argument. Matt ___ 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
Re: Maintaining backwards compatibility with swap macros
On 4 October 2011 16:51, Matt Turner wrote: > On Tue, Oct 4, 2011 at 2:33 PM, Michal Suchanek wrote: >> BTW it adds a warning about stuff variable being unused - probably >> defined in one of the macros. > > It's because the swap macros stopped taking a second argument. No, that would be the 'n' variable which you patched out already. Thanks Michal ___ 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
Re: Maintaining backwards compatibility with swap macros
On Tue, Oct 4, 2011 at 2:55 PM, Michal Suchanek wrote: > On 4 October 2011 16:51, Matt Turner wrote: >> On Tue, Oct 4, 2011 at 2:33 PM, Michal Suchanek wrote: >>> BTW it adds a warning about stuff variable being unused - probably >>> defined in one of the macros. >> >> It's because the swap macros stopped taking a second argument. > > No, that would be the 'n' variable which you patched out already. Then I have no idea what you're talking about. ___ 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
Re: Maintaining backwards compatibility with swap macros
On 4 October 2011 16:57, Matt Turner wrote: > On Tue, Oct 4, 2011 at 2:55 PM, Michal Suchanek wrote: >> On 4 October 2011 16:51, Matt Turner wrote: >>> On Tue, Oct 4, 2011 at 2:33 PM, Michal Suchanek wrote: BTW it adds a warning about stuff variable being unused - probably defined in one of the macros. >>> >>> It's because the swap macros stopped taking a second argument. >> >> No, that would be the 'n' variable which you patched out already. > > Then I have no idea what you're talking about. > ../../Xext/xselinux_ext.c: In function ‘SProcSELinuxQueryVersion’: ../../Xext/xselinux_ext.c:529:5: warning: unused variable ‘stuff’ [-Wunused-variable] ___ 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
Re: Maintaining backwards compatibility with swap macros
Hi, On 4 October 2011 16:00, Michal Suchanek wrote: > On 4 October 2011 16:57, Matt Turner wrote: >> On Tue, Oct 4, 2011 at 2:55 PM, Michal Suchanek wrote: >>> On 4 October 2011 16:51, Matt Turner wrote: On Tue, Oct 4, 2011 at 2:33 PM, Michal Suchanek wrote: > BTW it adds a warning about stuff variable being unused - probably > defined in one of the macros. It's because the swap macros stopped taking a second argument. >>> >>> No, that would be the 'n' variable which you patched out already. >> >> Then I have no idea what you're talking about. >> > ../../Xext/xselinux_ext.c: In function ‘SProcSELinuxQueryVersion’: > ../../Xext/xselinux_ext.c:529:5: warning: unused variable ‘stuff’ > [-Wunused-variable] 'stuff' is the request variable generated by the REQUEST_* macros (stupid name, I know). Since SProcSELinuxQueryVersion no longer touches the macro, you can just delete the REQUEST_* macro and make it simply return ProcSELinuxQueryVersion(client). Cheers, Daniel ___ 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
Re: [PULL] prep work for screen crossing fixes
On Tue, 4 Oct 2011 14:15:53 +1000, Peter Hutterer wrote: > is it ever other than 0/0? It's up to the DDX to set these values. The Quarz backend pulls the geometry out of the operating system and assigns the same values to the X screens. kdrive lets the user specify the x/y values on the command line. xf86 provides the 'absolute' keyword for specifying screen positions. So, I think we can pretty safely say that x/y are *not* always 0/0, even though they probably should be. -- keith.pack...@intel.com pgpCXSrihpSA8.pgp Description: PGP signature ___ 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
[PATCH xserver] Fix FP3232 related issues.
From: Michel Dänzer
Make check has been broken since commit
f32c827d513c44f07e1d0fbcc0c96cef18c9a4d9 ('Input: Fix frac calculation on
[Raw]DeviceEvent conversion').
* Use floor() instead of trunc() in order to achieve the inverse of
FP3232.integral + FP3232.frac / (1ULL << 32)
even for negative floating point numbers.
* Use (1ULL << 32) instead of (1 << 16) * (1 << 16) in order to save one
floating point multiplication.
* Fix up test code.
Signed-off-by: Michel Dänzer
---
Xi/xiquerydevice.c| 10 ++
dix/eventconvert.c| 12 ++--
test/xi2/protocol-eventconvert.c | 12 ++--
test/xi2/protocol-xiquerydevice.c |4 ++--
4 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/Xi/xiquerydevice.c b/Xi/xiquerydevice.c
index 9961d1b..fb70357 100644
--- a/Xi/xiquerydevice.c
+++ b/Xi/xiquerydevice.c
@@ -351,8 +351,9 @@ ListValuatorInfo(DeviceIntPtr dev, xXIValuatorInfo* info,
int axisnumber,
info->min.frac = 0;
info->max.integral = v->axes[axisnumber].max_value;
info->max.frac = 0;
-info->value.integral = (int)v->axisVal[axisnumber];
-info->value.frac = (int)(v->axisVal[axisnumber] * (1 << 16) * (1 << 16));
+info->value.integral = floor(v->axisVal[axisnumber]);
+info->value.frac = (v->axisVal[axisnumber] - info->value.integral) *
+(1ULL << 32);
info->resolution = v->axes[axisnumber].resolution;
info->number = axisnumber;
info->mode = valuator_get_mode(dev, axisnumber);
@@ -402,8 +403,9 @@ ListScrollInfo(DeviceIntPtr dev, xXIScrollInfo *info, int
axisnumber)
ErrorF("[Xi] Unknown scroll type %d. This is a bug.\n",
axis->scroll.type);
break;
}
-info->increment.integral = (int)axis->scroll.increment;
-info->increment.frac = (unsigned int)(axis->scroll.increment * (1UL << 16)
* (1UL << 16));
+info->increment.integral = floor(axis->scroll.increment);
+info->increment.frac = (axis->scroll.increment - info->increment.integral)
*
+(1ULL << 32);
info->sourceid = v->sourceid;
info->flags = 0;
diff --git a/dix/eventconvert.c b/dix/eventconvert.c
index f9aafa5..3fc29e3 100644
--- a/dix/eventconvert.c
+++ b/dix/eventconvert.c
@@ -633,9 +633,9 @@ eventToDeviceEvent(DeviceEvent *ev, xEvent **xi)
if (BitIsOn(ev->valuators.mask, i))
{
SetBit(ptr, i);
-axisval->integral = trunc(ev->valuators.data[i]);
+axisval->integral = floor(ev->valuators.data[i]);
axisval->frac = (ev->valuators.data[i] - axisval->integral) *
-(1 << 16) * (1 << 16);
+(1ULL << 32);
axisval++;
}
}
@@ -678,13 +678,13 @@ eventToRawEvent(RawDeviceEvent *ev, xEvent **xi)
if (BitIsOn(ev->valuators.mask, i))
{
SetBit(ptr, i);
-axisval->integral = trunc(ev->valuators.data[i]);
+axisval->integral = floor(ev->valuators.data[i]);
axisval->frac = (ev->valuators.data[i] - axisval->integral) *
-(1 << 16) * (1 << 16);
-axisval_raw->integral = trunc(ev->valuators.data_raw[i]);
+(1ULL << 32);
+axisval_raw->integral = floor(ev->valuators.data_raw[i]);
axisval_raw->frac =
(ev->valuators.data_raw[i] - axisval_raw->integral) *
- (1 << 16) * (1 << 16);
+ (1ULL << 32);
axisval++;
axisval_raw++;
}
diff --git a/test/xi2/protocol-eventconvert.c b/test/xi2/protocol-eventconvert.c
index bfa23b5..fc82747 100644
--- a/test/xi2/protocol-eventconvert.c
+++ b/test/xi2/protocol-eventconvert.c
@@ -104,8 +104,8 @@ static void test_values_XIRawEvent(RawDeviceEvent *in,
xXIRawEvent *out,
value = (FP3232*)(((unsigned char*)&out[1]) + out->valuators_len *
4);
value += nvals;
-vi.integral = trunc(in->valuators.data[i]);
-vi.frac = in->valuators.data[i] - vi.integral;
+vi.integral = floor(in->valuators.data[i]);
+vi.frac = (in->valuators.data[i] - vi.integral) * (1ULL << 32);
vo.integral = value->integral;
vo.frac = value->frac;
@@ -120,8 +120,8 @@ static void test_values_XIRawEvent(RawDeviceEvent *in,
xXIRawEvent *out,
raw_value = value + bits_set;
-vi.integral = trunc(in->valuators.data_raw[i]);
-vi.frac = in->valuators.data_raw[i] - vi.integral;
+vi.integral = floor(in->valuators.data_raw[i]);
+vi.frac = (in->valuators.data_raw[i] - vi.integral) * (1ULL << 32);
vo.integral = raw_value->integral;
vo.frac = raw_value->frac;
@@ -390,8 +390,8 @@ static void test_values_XIDeviceEvent(DeviceEvent *in,
xXIDeviceEvent *out,
{
FP3232 vi, vo;
-vi.integral = trunc(in-
Re: [PATCH xserver] Fix FP3232 related issues.
Hi,
2011/10/4 Michel Dänzer :
> From: Michel Dänzer
>
> Make check has been broken since commit
> f32c827d513c44f07e1d0fbcc0c96cef18c9a4d9 ('Input: Fix frac calculation on
> [Raw]DeviceEvent conversion').
>
> * Use floor() instead of trunc() in order to achieve the inverse of
>
> FP3232.integral + FP3232.frac / (1ULL << 32)
>
> even for negative floating point numbers.
> * Use (1ULL << 32) instead of (1 << 16) * (1 << 16) in order to save one
> floating point multiplication.
> * Fix up test code.
As discussed recently, the * (1 << 16) * (1 << 16) was a fix for
32-bit systems which can't get their head around large numbers; even
so, see the thread where Jeremy, Peter and myself discuss creating a
helper function for this using ldexp().
Cheers,
Daniel
___
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
Re: [PULL] build fix, GC clipping cleanup
On Mon, 3 Oct 2011 23:46:10 -0700, Jamey Sharp wrote: > Quit wrapping ChangeClip, CopyClip, and DestroyClip in GCFuncs. Good fix > Make GC clientClip always be a region. Good fix. > Introduce ReleasePixmap to unreference, call screen hooks, and free. This one seems very problematic. You've essentially changed the semantics of the DestroyPixmap screen function without changing it's name or type signature. Catching mis-use of this is going to be a challenge. > Introduce CreatePixmap, allocating a header and calling screen hooks. This one seems easy enough to fix drivers to match; the code won't compile until you repair it. For this and DestroyPixmap, I wonder if we should be having the drivers manage the list of callbacks explicitly, or if they should just be callback lists which DIX runs over? > Move pixmap size limit checking to CreatePixmap, from screen hooks. Quite sensible -- keith.pack...@intel.com pgpzvRKgsMB51.pgp Description: PGP signature ___ 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
Re: Maintaining backwards compatibility with swap macros
On 4 October 2011 17:18, Daniel Stone wrote:
> Hi,
>
> On 4 October 2011 16:00, Michal Suchanek wrote:
>> On 4 October 2011 16:57, Matt Turner wrote:
>>> On Tue, Oct 4, 2011 at 2:55 PM, Michal Suchanek wrote:
On 4 October 2011 16:51, Matt Turner wrote:
> On Tue, Oct 4, 2011 at 2:33 PM, Michal Suchanek
> wrote:
>> BTW it adds a warning about stuff variable being unused - probably
>> defined in one of the macros.
>
> It's because the swap macros stopped taking a second argument.
No, that would be the 'n' variable which you patched out already.
>>>
>>> Then I have no idea what you're talking about.
>>>
>> ../../Xext/xselinux_ext.c: In function ‘SProcSELinuxQueryVersion’:
>> ../../Xext/xselinux_ext.c:529:5: warning: unused variable ‘stuff’
>> [-Wunused-variable]
>
> 'stuff' is the request variable generated by the REQUEST_* macros
> (stupid name, I know). Since SProcSELinuxQueryVersion no longer
> touches the macro, you can just delete the REQUEST_* macro and make it
> simply return ProcSELinuxQueryVersion(client).
>
Yes, removing that also fixes the warning.
Attaching updated patch.
Thanks
Michal
From e0628cee60f9de96f4f229bc9e618113c532251c Mon Sep 17 00:00:00 2001
From: Matt Turner
Date: Tue, 4 Oct 2011 10:01:50 -0400
Subject: [PATCH] Fix xselinux after swap change
Signed-off-by: Matt Turner
---
Xext/xselinux_ext.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
Index: xserver/Xext/xselinux_ext.c
===
--- xserver.orig/Xext/xselinux_ext.c 2011-10-04 17:16:29.0 +0200
+++ xserver/Xext/xselinux_ext.c 2011-10-04 18:05:29.0 +0200
@@ -337,7 +337,7 @@
SELinuxSendItemsToClient(ClientPtr client, SELinuxListItemRec *items,
int size, int count)
{
-int rc, k, n, pos = 0;
+int rc, k, pos = 0;
SELinuxListItemsReply rep;
CARD32 *buf;
@@ -526,11 +526,7 @@
static int
SProcSELinuxQueryVersion(ClientPtr client)
{
-REQUEST(SELinuxQueryVersionReq);
-
REQUEST_SIZE_MATCH(SELinuxQueryVersionReq);
-swaps(&stuff->client_major);
-swaps(&stuff->client_minor);
return ProcSELinuxQueryVersion(client);
}
___
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
Re: [PULL] build fix, GC clipping cleanup
On 4 October 2011 18:07, Keith Packard wrote: > On Mon, 3 Oct 2011 23:46:10 -0700, Jamey Sharp wrote: > >> Quit wrapping ChangeClip, CopyClip, and DestroyClip in GCFuncs. > > Good fix > >> Make GC clientClip always be a region. > > Good fix. > >> Introduce ReleasePixmap to unreference, call screen hooks, and free. > > This one seems very problematic. You've essentially changed the > semantics of the DestroyPixmap screen function without changing it's > name or type signature. Catching mis-use of this is going to be a > challenge. > Wasn't it just renamed from DestroyPixmap to ReleasePixmap? Thanks Michal ___ 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
Re: [PULL] build fix, GC clipping cleanup
On Tue, 4 Oct 2011 18:19:54 +0200, Michal Suchanek wrote: > Wasn't it just renamed from DestroyPixmap to ReleasePixmap? The function was renamed, but the screen structure member was not (nor should it have been -- it's now actually called when the pixmap is destroyed, not just when dereferenced). Oh, this patch sequence should *definitely* come with an ABI bump; there's no way you can change driver source code so it can build with either version... -- keith.pack...@intel.com pgpnlXTUmVJKU.pgp Description: PGP signature ___ 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
Re: [PULL] build fix, GC clipping cleanup
On 10/04/2011 09:33 AM, Keith Packard wrote: On Tue, 4 Oct 2011 18:19:54 +0200, Michal Suchanek wrote: Wasn't it just renamed from DestroyPixmap to ReleasePixmap? The function was renamed, but the screen structure member was not (nor should it have been -- it's now actually called when the pixmap is destroyed, not just when dereferenced). Oh, this patch sequence should *definitely* come with an ABI bump; there's no way you can change driver source code so it can build with either version... With the old CreatePixmap API, drivers could override the width and height when calling down to prevent the fb layer from allocating the pixmap memory, and then plug in its own. It looks like a driver could do the same thing now by changing the pixmap structure's width and height to 0 temporarily, but it looks like that will cause the new code to call malloc(0) and then fail if it returns NULL. -- Aaron ___ 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
Re: [PULL] build fix, GC clipping cleanup
On Tue, 4 Oct 2011 12:37:59 -0700, Aaron Plattner wrote: > With the old CreatePixmap API, drivers could override the width and > height when calling down to prevent the fb layer from allocating the > pixmap memory, and then plug in its own. It looks like a driver could > do the same thing now by changing the pixmap structure's width and > height to 0 temporarily, but it looks like that will cause the new code > to call malloc(0) and then fail if it returns NULL. Might make sense to have the fb code *not* allocate memory if devPrivate.ptr is non-zero? -- keith.pack...@intel.com pgpM4xyT5j0xZ.pgp Description: PGP signature ___ 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
[RFC modular] Publish.sh: batch release and autotagging of modules
Features: - Navigate the build tree from a given list of modules to release - Accepts a list in the format produced by build.sh -L - Tag and version names picked-up from Makefile - Section name picked-up from module list - It only release tarballs it has created from the module - Timely feedback, extensive error checking and final report - Leave module untouched if already released - Recover from a failed run with --autoresume - Verify what will happen with --dry-run - Generate the announce e-mail - Update the jhbuild moduleset Example: util/modular/publish.sh app/xdm lib/libX11-1.1.3 mesa/drm xserver In this example, libX11-1.1.3 would be at branch 1.1.3 and could be released in the same batch run with libX11 master. The last subdir name does not matter. Design --- The new script is called "publish" for the moment as it may complement or replace the release script. It is yet to be seen. The development process ends with a module whose last commit is a version bump in the fdo repository. All testing is assumed to have been done. The user is not asked to do anything with git tags. No harm done if user tags the module with the correct tag name. Any non conforming tag will be ignored. The srcipt runs 'make dist' to create the tarball. We don't have to prompt the user for the tar name, the version number or the section name. The "section" is technically the first subdir down from the script invocation directory. For all but a few, it mathces the subdir on host /svr where the tarballs are uploaded. There may be zero or one subdir below the "section". Exceptions such as mesa/drm have custom code to handle. Interface - Usage: publish.sh [options] section[/module]... Section: app|data|doc|driver|font|lib|mesa|pixman|proto|util|xcb| xkeyboard-config|xserver Module: One optional subdirectory (name does not matter) for a git module. Options: --autoresume Resume publishing modules from last attempt. Use --dry-run Does everything except tagging and uploading tarballs --force Force overwritting an existing release --help Display this help and exit successfully --modfile Publish the section/modules specified in --moduleset The jhbuild moduleset full pathname to be updated --no-quit Do not quit after error; just print error message --userUsername of your fdo account if not configured in ssh Environment variables defined by the "make" program and used by publish.sh: MAKEThe name of the make command [make] MAKEFLAGS: Options to pass to all $(MAKE) invocations Usage Scenarios Due to a change to the m4 macro, all font packages need to released. util/modular/build.sh -L | grep font/ > myList.txt util/modular/publish.sh --autoresume resume.txt --modfile myList.txt A developer is asking a buddy to relase a few protocols and libraries. He sends the list in an e-mail. Once all is done on disk: edit myList.txt (or save from e-mail) util/modular/publish.sh --no-quit --modfile myList.txt A single app needs to be released for an important bug fix util/modular/publish.sh app/xdm Supports libdrm and xkeybboard-config: util/modular/publish.sh xkeyboard-config mesa/drm Signed-off-by: Gaetan Nadon --- Might as well get comments now before I do detailed testing. Questions/issues for reviewers: Should pgp signature be included by default for taggging? Anyone seen a tag called "initial"? as in: case "$tag_previous" in initial) The name of the remote repo being tracked is obtained from git-config. It cannot be suppiled on the cmd line as it can vary by module. No local changes allowed and no override permitted. The script only publishes the tarballs it creates from a clean module. Safety first. Just clone the repo into a different subdir in the same section to leave your development local repo untouched. readlink (for jh module set) is not portable (missing on Solaris) and has not been retained. Replacement? Platform check? The private versioning scheme for intel video driver has not been retained. http://cgit.freedesktop.org/xorg/util/modular/commit/release.sh?id=520f454a0e57ba4d9a411fac3c17dc096297c66e publish.sh | 665 1 files changed, 665 insertions(+), 0 deletions(-) create mode 100755 publish.sh diff --git a/publish.sh b/publish.sh new file mode 100755 index 000..5ff7454 --- /dev/null +++ b/publish.sh @@ -0,0 +1,665 @@ +#!/bin/sh +# +# Creates and upload a git module tarball +# +# Note on portability: +# This script is intended to run on any platform supported by X.Org. +# Basically, it should be able to run in a Bourne shell. +# +# + +export LC_ALL=C +#set -x + +#-- +# Function: check_local_changes +#-- +# +check_
Re: [PULL] build fix, GC clipping cleanup
On 10/04/2011 12:43 PM, Keith Packard wrote: * PGP Signed by an unknown key On Tue, 4 Oct 2011 12:37:59 -0700, Aaron Plattner wrote: With the old CreatePixmap API, drivers could override the width and height when calling down to prevent the fb layer from allocating the pixmap memory, and then plug in its own. It looks like a driver could do the same thing now by changing the pixmap structure's width and height to 0 temporarily, but it looks like that will cause the new code to call malloc(0) and then fail if it returns NULL. Might make sense to have the fb code *not* allocate memory if devPrivate.ptr is non-zero? Oh, you mean have the driver allocate the storage before calling down? Yeah, that's a good idea. -- Aaron ___ 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
[PATCH evdev, v2] Support smooth scrolling on wheel emulation
This adds support for the new smooth-scrolling valuator system to
the wheel emulation code.
Caveats:
- Enabling wheel emulation at runtime does not work if the device
does not provide the necessary axes already.
- Horizontal scrolling is always reported on the REL_HWHEEL axis,
ignoring a REL_DIAL axis present in hardware.
Signed-off-by: Max Schwarz
---
Resend, my E-Mail client ate the patch...
src/emuWheel.c | 19 ++-
src/evdev.c| 34 +++---
src/evdev.h|4 +++-
3 files changed, 48 insertions(+), 9 deletions(-)
diff --git a/src/emuWheel.c b/src/emuWheel.c
index ae894fa..0439a5b 100644
--- a/src/emuWheel.c
+++ b/src/emuWheel.c
@@ -167,9 +167,13 @@ static int
EvdevWheelEmuInertia(InputInfoPtr pInfo, WheelAxisPtr axis, int value)
{
EvdevPtr pEvdev = (EvdevPtr)pInfo->private;
+int rc = 0;
+#ifndef HAVE_SMOOTH_SCROLLING
int button;
int inertia;
-int rc = 0;
+#else
+ double v;
+#endif
/* if this axis has not been configured, just eat the motion */
if (!axis->up_button)
@@ -177,6 +181,7 @@ EvdevWheelEmuInertia(InputInfoPtr pInfo, WheelAxisPtr
axis, int value)
axis->traveled_distance += value;
+#ifndef HAVE_SMOOTH_SCROLLING
if (axis->traveled_distance < 0) {
button = axis->up_button;
inertia = -pEvdev->emulateWheel.inertia;
@@ -192,6 +197,14 @@ EvdevWheelEmuInertia(InputInfoPtr pInfo, WheelAxisPtr
axis, int value)
rc++;
}
return rc;
+#else
+/* Inject relative valuator delta */
+v = -((double)axis->traveled_distance) / pEvdev->emulateWheel.inertia;
+EvdevInjectRelativeMotion(pEvdev, axis->code, v);
+axis->traveled_distance = 0;
+xf86IDrvMsg(pInfo, X_ERROR, "rel motion: %f\n", v);
+return 1;
+#endif
}
/* Handle button mapping here to avoid code duplication,
@@ -322,6 +335,10 @@ EvdevWheelEmuPreInit(InputInfoPtr pInfo)
pEvdev->emulateWheel.X.traveled_distance = 0;
pEvdev->emulateWheel.Y.traveled_distance = 0;
+/* Used to inject smooth scrolling events */
+pEvdev->emulateWheel.X.code = REL_HWHEEL;
+pEvdev->emulateWheel.Y.code = REL_WHEEL;
+
xf86IDrvMsg(pInfo, X_CONFIG,
"EmulateWheelButton: %d, "
"EmulateWheelInertia: %d, "
diff --git a/src/evdev.c b/src/evdev.c
index 2281206..9559758 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -362,7 +362,7 @@ EvdevProcessValuators(InputInfoPtr pInfo)
{
int tmp;
EvdevPtr pEvdev = pInfo->private;
-int *delta = pEvdev->delta;
+double *delta = pEvdev->delta;
/* convert to relative motion for touchpads */
if (pEvdev->abs_queued && (pEvdev->flags & EVDEV_RELATIVE_MODE)) {
@@ -413,7 +413,7 @@ EvdevProcessValuators(InputInfoPtr pInfo)
{
int map = pEvdev->axis_map[i];
if (pEvdev->delta[i] && map != -1)
-valuator_mask_set(pEvdev->vals, map, pEvdev->delta[i]);
+valuator_mask_set_double(pEvdev->vals, map, pEvdev-
>delta[i]);
}
}
/*
@@ -586,7 +586,6 @@ EvdevProcessRelativeMotionEvent(InputInfoPtr pInfo, struct
input_event *ev)
{
int value;
EvdevPtr pEvdev = pInfo->private;
-int map;
/* Get the signed value, earlier kernels had this as unsigned */
value = ev->value;
@@ -618,15 +617,25 @@ EvdevProcessRelativeMotionEvent(InputInfoPtr pInfo,
struct input_event *ev)
if (EvdevWheelEmuFilterMotion(pInfo, ev))
return;
-pEvdev->rel_queued = 1;
-pEvdev->delta[ev->code] += value;
-map = pEvdev->axis_map[ev->code];
-valuator_mask_set(pEvdev->vals, map, value);
+EvdevInjectRelativeMotion(pEvdev, ev->code, value);
break;
}
}
/**
+ * Inject a relative motion on a valuator axis.
+ **/
+void
+EvdevInjectRelativeMotion(EvdevPtr pEvdev, int axis_code, double delta)
+{
+ int map = pEvdev->axis_map[axis_code];
+
+ pEvdev->rel_queued = 1;
+ pEvdev->delta[axis_code] += delta;
+ valuator_mask_set_double(pEvdev->vals, map, delta);
+}
+
+/**
* Take the absolute motion input event and process it accordingly.
*/
static void
@@ -896,6 +905,7 @@ EvdevReadInput(InputInfoPtr pInfo)
}
#define TestBit(bit, array) ((array[(bit) / LONG_BITS]) & (1L << ((bit) %
LONG_BITS)))
+#define evdev_SetBit(bit, array) ((array[(bit) / LONG_BITS]) |= (1L << ((bit)
% LONG_BITS)))
static void
EvdevPtrCtrlProc(DeviceIntPtr device, PtrCtrl *ctrl)
@@ -1099,6 +1109,16 @@ EvdevAddRelValuatorClass(DeviceIntPtr device)
if (!TestBit(EV_REL, pEvdev->bitmask))
goto out;
+#ifdef HAVE_SMOOTH_SCROLLING
+/* If wheel emulation is enabled, we need to report virtual axes */
+if (pEvdev->emulateWheel.enabled) {
+if(pEvdev->emulateWheel.X.up_button)
+evdev_SetBit(REL_HWHEEL, pEvdev->rel_bitmask);
+if(pEvdev->emulateWheel.Y.up_button)
+evdev_SetBit(R
Re: [PULL] build fix, GC clipping cleanup
On Tue, 4 Oct 2011 12:47:22 -0700, Aaron Plattner wrote: > Oh, you mean have the driver allocate the storage before calling down? > Yeah, that's a good idea. Thinking about how this mixes in with my idea of just using the existing callback infrastructure instead of using wrappers -- the current scheme makes it clear what order things are done in; fb is initialized, then the driver initializes on top of that, leaving it in control of the CreatePixmap hook. With callbacks, we'd need to make who gets called explicit, and for CreatePixmap, we probably want a different order than DestroyPixmap. -- keith.pack...@intel.com pgp2OCqfYouKg.pgp Description: PGP signature ___ 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
Re: [PULL] prep work for screen crossing fixes
On 2011-10-04 01:35, Peter Hutterer wrote: > On Mon, Oct 03, 2011 at 10:02:28PM -0700, Jamey Sharp wrote: >> On Tue, Oct 04, 2011 at 02:15:53PM +1000, Peter Hutterer wrote: >>> On Mon, Oct 03, 2011 at 09:02:19PM -0700, Keith Packard wrote: On Tue, 4 Oct 2011 13:26:35 +1000, Peter Hutterer wrote: Non-text part: multipart/signed > Store desktop dimensions in screenInfo. Do we need the minimum x/y of the desktop too? >>> >>> is it ever other than 0/0? >> >> Sure, that's legal (though crazy). Besides the xorg.conf ServerLayout >> syntax for positioning a Screen "RightOf", "Below", etc, you can also >> set the screen's absolute position. > > right, that's for a single screen. but can the desktop origin ever be > non-zero? Can you have layout where the first screen goes from say -1024..0 > and the second from 0..1204? Sure. That's not even crazy, that's normal. Pre-randr-1.3 desktops (and display managers) typically interpret that as "Primary screen starts at 0,0" so they know which monitor the user wants the main menu button/bar (or login dialog) on. (Explicit SetPrimary/GetPrimary requests were only added in randr 1.3) Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ 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
[PATCH] dix: fix inverted handling of legacy scroll button events
This bug led to inverted scrolling axes with legacy drivers that
do not support smooth scrolling classes.
Signed-off-by: Max Schwarz
---
Applies on Peter's next branch.
dix/getevents.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/dix/getevents.c b/dix/getevents.c
index ebf2653..97c3937 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -1330,21 +1330,22 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr
pDev, int type,
double val, adj;
int axis;
+/* Up is negative on valuators, down positive */
switch (buttons) {
case 4:
-adj = 1.0;
+adj = -1.0;
axis = v_scroll_axis;
break;
case 5:
-adj = -1.0;
+adj = 1.0;
axis = v_scroll_axis;
break;
case 6:
-adj = 1.0;
+adj = -1.0;
axis = h_scroll_axis;
break;
case 7:
-adj = -1.0;
+adj = 1.0;
axis = h_scroll_axis;
break;
default:
--
1.7.4.1
___
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
Re: [PATCH 12/12] input: change pointer screen crossing behaviour for multiple ScreenRecs
On Tue, Oct 04, 2011 at 04:03:56PM +0200, Michal Suchanek wrote: > The X server off two-screen-coordinates branch builds and runs in > two-csreen configuration with a mouse. cool, thanks for testing. > However, the XI tests shipped with the X server fail. Worse, they crash. yeah, the tests all work with assert(). The test failure is caused by another issue in f32c827d513c44f07e1d0fbcc0c96cef18c9a4d9 afaict Cheers, Peter ___ 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
Re: [PATCH 1/3] Move miTrapezoids() into fb as fbTrapezoids().
This caused a performance regression because previously, miTrapezoids
would render its mask image into a scratch pixmap and then perform the
final composite using a possibly-accelerated RENDER Composite call.
Now, fbTrapezoids does the final composite in software, leading to, for
example, http://www.nvnews.net/vbulletin/showthread.php?t=166698
Of course, I could simply copy the old miTrapezoids implementation into
our driver, but it seems hard to believe that our driver is the only one
that benefited from the "rasterize in software, composite in hardware"
behavior of the old code. Should I re-add miTrapezoids as a helper that
drivers can plug in when they want the old behavior, just revert this
change, or go the "only nvidia gets to go fast" copy & paste route?
On 02/11/2011 06:54 AM, "Søren Sandmann Pedersen" "
wrote:
From: Søren Sandmann Pedersen
The main consumer of trapezoids, cairo, is using the Trapezoids
request, which is currently implemented in the miTrapezoids()
function. That function splits the request into smaller bits and calls
lower level functions such as AddTrap.
By moving the implementation of the whole request into fb, we can
instead call pixman_composite_trapezoids() to do the whole request in
one step.
There are no callers of miTrapezoids in any of the open source
drivers, although exa and uxa have their own copies of the function.
Signed-off-by: Søren Sandmann
---
fb/fbpict.c |1 +
fb/fbpict.h | 10 ++
fb/fbtrap.c | 83 +--
render/mipict.c |2 +-
render/mipict.h | 10 --
render/mitrap.c | 61
6 files changed, 92 insertions(+), 75 deletions(-)
diff --git a/fb/fbpict.c b/fb/fbpict.c
index 7636040..6e66db8 100644
--- a/fb/fbpict.c
+++ b/fb/fbpict.c
@@ -364,6 +364,7 @@ fbPictureInit (ScreenPtr pScreen, PictFormatPtr formats,
int nformats)
ps->Glyphs = miGlyphs;
ps->CompositeRects = miCompositeRects;
ps->RasterizeTrapezoid = fbRasterizeTrapezoid;
+ps->Trapezoids = fbTrapezoids;
ps->AddTraps = fbAddTraps;
ps->AddTriangles = fbAddTriangles;
diff --git a/fb/fbpict.h b/fb/fbpict.h
index 9abced1..03d2665 100644
--- a/fb/fbpict.h
+++ b/fb/fbpict.h
@@ -65,4 +65,14 @@ fbAddTriangles (PicturePtr pPicture,
int ntri,
xTriangle *tris);
+extern _X_EXPORT void
+fbTrapezoids (CARD8op,
+ PicturePtrpSrc,
+ PicturePtrpDst,
+ PictFormatPtr maskFormat,
+ INT16 xSrc,
+ INT16 ySrc,
+ int ntrap,
+ xTrapezoid*traps);
+
#endif /* _FBPICT_H_ */
diff --git a/fb/fbtrap.c b/fb/fbtrap.c
index c309ceb..687de55 100644
--- a/fb/fbtrap.c
+++ b/fb/fbtrap.c
@@ -123,9 +123,9 @@ fbAddTriangles (PicturePtr pPicture,
* / \ / \
*/ \ / \
* / + + \
-* /-- --\
-* / -- -- \
-*/ --- --- \
+* /-- --\
+* / -- -- \
+*/ --- --- \
* +-- --+
*/
@@ -157,3 +157,80 @@ fbAddTriangles (PicturePtr pPicture,
}
}
+
+void
+fbTrapezoids (CARD8op,
+ PicturePtrpSrc,
+ PicturePtrpDst,
+ PictFormatPtr maskFormat,
+ INT16 xSrc,
+ INT16 ySrc,
+ int ntrap,
+ xTrapezoid*traps)
+{
+pixman_image_t *src, *dst;
+int src_xoff, src_yoff;
+int dst_xoff, dst_yoff;
+
+if (ntrap == 0)
+ return;
+
+src = image_from_pict (pSrc, FALSE,&src_xoff,&src_yoff);
+dst = image_from_pict (pDst, TRUE,&dst_xoff,&dst_yoff);
+
+if (src&& dst)
+{
+ pixman_format_code_t format;
+ int x_dst, y_dst;
+ int i;
+
+ x_dst = traps[0].left.p1.x>> 16;
+ y_dst = traps[0].left.p1.y>> 16;
+
+ if (!maskFormat)
+ {
+ if (pDst->polyEdge == PolyEdgeSharp)
+ format = PIXMAN_a1;
+ else
+ format = PIXMAN_a8;
+
+ for (i = 0; i< ntrap; ++i)
+ {
+ pixman_composite_trapezoids (op, src, dst, format,
+xSrc + src_xoff,
+ySrc + src_yoff,
+x_dst + dst_xoff,
+y_dst + dst_yoff,
+1, (pixman_trapezoid_t *)traps++);
+ }
+ }
+ else
+ {
+ switch (PICT_FORMAT_A (maskFormat->format))
+ {
+ case 1:
+ format = PIXMAN_a1
[PATCH] dix: add utility functions for double to/fro FP1616/FP3232 conversion
Co-authored by Jeremy Huddleston
Signed-off-by: Peter Hutterer
---
Jeremy, these are your functions fixed up to pass the tests (a few bitshifts
where wrong).
Changes to your version:
- use trunc instad of (double)(int)(double_value)
- use rint(trunc()) instead of (int) to silence gcc
- fix a few wrong bitshifts/masks
- fix < 0 to < 1 for fabs(frac)
dix/inpututils.c | 68
include/inpututils.h |6 +++
test/input.c | 120 ++
3 files changed, 194 insertions(+), 0 deletions(-)
diff --git a/dix/inpututils.c b/dix/inpututils.c
index 582135e..c27e16c 100644
--- a/dix/inpututils.c
+++ b/dix/inpututils.c
@@ -821,3 +821,71 @@ input_option_set_value(InputOption *opt, const char *value)
if (value)
opt->value = strdup(value);
}
+
+
+/* FP1616/FP3232 conversion functions */
+double
+fp1616_to_double(FP1616 in)
+{
+double ret;
+ret = (double)(in >> 16);
+ret += ldexp((double)(in & 0x), -16);
+return ret;
+}
+
+double
+fp3232_to_double(FP3232 in)
+{
+double ret;
+ret = (double)in.integral;
+ret += ldexp((double)in.frac, -32);
+return ret;
+}
+
+
+FP1616
+double_to_fp1616(double in)
+{
+FP1616 ret;
+int32_t integral;
+double frac_f;
+uint32_t frac_d;
+
+integral = (int32_t)in << 16;
+frac_f = in - trunc(in);
+
+if (fabs(frac_f) < 1) {
+ frac_d = rint(trunc(ldexp(frac_f, 16)));
+} else {
+ /* crap */
+ frac_d = 0;
+}
+
+ret = integral;
+ret |= frac_d & 0x;
+return ret;
+}
+
+FP3232
+double_to_fp3232(double in)
+{
+FP3232 ret;
+int32_t integral;
+double frac_f;
+uint32_t frac_d;
+
+integral = (int32_t)in;
+frac_f = in - trunc(in);
+
+if (fabs(frac_f) < 1) {
+ frac_d = rint(trunc(ldexp(frac_f,32)));
+} else {
+ /* crap */
+ frac_d = 0;
+}
+
+ret.integral = integral;
+ret.frac = frac_d;
+return ret;
+}
+
diff --git a/include/inpututils.h b/include/inpututils.h
index 47e242d..2832ed5 100644
--- a/include/inpututils.h
+++ b/include/inpututils.h
@@ -30,6 +30,7 @@
#define INPUTUTILS_H
#include "input.h"
+#include
struct _ValuatorMask {
int8_t last_bit; /* highest bit set in mask */
@@ -40,4 +41,9 @@ struct _ValuatorMask {
extern void verify_internal_event(const InternalEvent *ev);
extern void init_device_event(DeviceEvent *event, DeviceIntPtr dev, Time ms);
+FP3232 double_to_fp3232(double in);
+FP1616 double_to_fp1616(double in);
+double fp1616_to_double(FP1616 in);
+double fp3232_to_double(FP3232 in);
+
#endif
diff --git a/test/input.c b/test/input.c
index 5fb9a90..05ef3ac 100644
--- a/test/input.c
+++ b/test/input.c
@@ -1476,8 +1476,128 @@ static void input_option_test(void)
}
+static void
+_test_double_fp16_values(double d)
+{
+FP1616 fp16;
+double re;
+uint32_t frac;
+int32_t integral;
+
+if (d > 0x7FFF) {
+printf("Test out of range\n");
+assert(0);
+}
+
+frac = rint(trunc(ldexp(d - trunc(d), 16)));
+integral = ((int16_t)d) << 16;
+
+fp16 = double_to_fp1616(d);
+re = fp1616_to_double(fp16);
+
+/* printf("FP16: double: %f fp16: %u int: %u frac: %u re:%f\n", d, fp16,
integral, frac, re); */
+
+assert((fp16 & 0x) == integral);
+assert((fp16 & 0x) == frac);
+
+re = fp1616_to_double(fp16);
+/* since we lose precision, we only do rough range testing */
+assert(re > d - 0.1);
+assert(re < d + 0.1);
+
+}
+
+static void
+_test_double_fp32_values(double d)
+{
+FP3232 fp32;
+double re;
+uint32_t frac;
+int32_t integral;
+
+if (d > 0x7FFF) {
+printf("Test out of range\n");
+assert(0);
+}
+
+frac = rint(trunc(ldexp(d - trunc(d), 32)));
+integral = ((int32_t)d);
+
+fp32 = double_to_fp3232(d);
+re = fp3232_to_double(fp32);
+
+/* printf("FP32: double: %f fp32: %u.%u int: %u frac: %u re:%f\n", d,
fp32.integral, fp32.frac, integral, frac, re); */
+
+assert(fp32.integral == integral);
+assert(fp32.frac == frac);
+
+re = fp3232_to_double(fp32);
+/* since we lose precision, we only do rough range testing */
+assert(re > d - 0.1);
+assert(re < d + 0.1);
+}
+
+static void
+dix_double_fp_conversion(void)
+{
+long i;
+printf("Testing double to FP1616/FP3232 conversions\n");
+
+_test_double_fp16_values(0);
+for (i = 1; i < 0x7FFF; i <<= 1) {
+double val;
+
+val = i;
+_test_double_fp16_values(val);
+_test_double_fp32_values(val);
+
+/* and some pseudo-random floating points */
+val = i + 0.00382;
+_test_double_fp16_values(val);
+_test_double_fp32_values(val);
+
+val = i + 0.05234;
+_test_double_fp16_values(val);
+_test_double_fp32_values(val);
+
+val = i + 0.12342;
+_test_double_fp16_values(val);
+_test_double_fp32_values(val);
+
+
Re: [PATCH evdev, v2] Support smooth scrolling on wheel emulation
On Tue, Oct 04, 2011 at 09:53:56PM +0200, Max Schwarz wrote:
> This adds support for the new smooth-scrolling valuator system to
> the wheel emulation code.
>
> Caveats:
> - Enabling wheel emulation at runtime does not work if the device
>does not provide the necessary axes already.
> - Horizontal scrolling is always reported on the REL_HWHEEL axis,
>ignoring a REL_DIAL axis present in hardware.
>
> Signed-off-by: Max Schwarz
> ---
> Resend, my E-Mail client ate the patch...
and it did so again, please re-send as attachment. or alternatively teach
your client not to wrap lines when sending patches.
Cheers,
Peter
>
> src/emuWheel.c | 19 ++-
> src/evdev.c| 34 +++---
> src/evdev.h|4 +++-
> 3 files changed, 48 insertions(+), 9 deletions(-)
>
> diff --git a/src/emuWheel.c b/src/emuWheel.c
> index ae894fa..0439a5b 100644
> --- a/src/emuWheel.c
> +++ b/src/emuWheel.c
> @@ -167,9 +167,13 @@ static int
> EvdevWheelEmuInertia(InputInfoPtr pInfo, WheelAxisPtr axis, int value)
> {
> EvdevPtr pEvdev = (EvdevPtr)pInfo->private;
> +int rc = 0;
> +#ifndef HAVE_SMOOTH_SCROLLING
> int button;
> int inertia;
> -int rc = 0;
> +#else
> + double v;
> +#endif
>
> /* if this axis has not been configured, just eat the motion */
> if (!axis->up_button)
> @@ -177,6 +181,7 @@ EvdevWheelEmuInertia(InputInfoPtr pInfo, WheelAxisPtr
> axis, int value)
>
> axis->traveled_distance += value;
>
> +#ifndef HAVE_SMOOTH_SCROLLING
> if (axis->traveled_distance < 0) {
> button = axis->up_button;
> inertia = -pEvdev->emulateWheel.inertia;
> @@ -192,6 +197,14 @@ EvdevWheelEmuInertia(InputInfoPtr pInfo, WheelAxisPtr
> axis, int value)
> rc++;
> }
> return rc;
> +#else
> +/* Inject relative valuator delta */
> +v = -((double)axis->traveled_distance) / pEvdev->emulateWheel.inertia;
> +EvdevInjectRelativeMotion(pEvdev, axis->code, v);
> +axis->traveled_distance = 0;
> +xf86IDrvMsg(pInfo, X_ERROR, "rel motion: %f\n", v);
> +return 1;
> +#endif
> }
>
> /* Handle button mapping here to avoid code duplication,
> @@ -322,6 +335,10 @@ EvdevWheelEmuPreInit(InputInfoPtr pInfo)
> pEvdev->emulateWheel.X.traveled_distance = 0;
> pEvdev->emulateWheel.Y.traveled_distance = 0;
>
> +/* Used to inject smooth scrolling events */
> +pEvdev->emulateWheel.X.code = REL_HWHEEL;
> +pEvdev->emulateWheel.Y.code = REL_WHEEL;
> +
> xf86IDrvMsg(pInfo, X_CONFIG,
> "EmulateWheelButton: %d, "
> "EmulateWheelInertia: %d, "
> diff --git a/src/evdev.c b/src/evdev.c
> index 2281206..9559758 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -362,7 +362,7 @@ EvdevProcessValuators(InputInfoPtr pInfo)
> {
> int tmp;
> EvdevPtr pEvdev = pInfo->private;
> -int *delta = pEvdev->delta;
> +double *delta = pEvdev->delta;
>
> /* convert to relative motion for touchpads */
> if (pEvdev->abs_queued && (pEvdev->flags & EVDEV_RELATIVE_MODE)) {
> @@ -413,7 +413,7 @@ EvdevProcessValuators(InputInfoPtr pInfo)
> {
> int map = pEvdev->axis_map[i];
> if (pEvdev->delta[i] && map != -1)
> -valuator_mask_set(pEvdev->vals, map, pEvdev->delta[i]);
> +valuator_mask_set_double(pEvdev->vals, map, pEvdev-
> >delta[i]);
> }
> }
> /*
> @@ -586,7 +586,6 @@ EvdevProcessRelativeMotionEvent(InputInfoPtr pInfo,
> struct
> input_event *ev)
> {
> int value;
> EvdevPtr pEvdev = pInfo->private;
> -int map;
>
> /* Get the signed value, earlier kernels had this as unsigned */
> value = ev->value;
> @@ -618,15 +617,25 @@ EvdevProcessRelativeMotionEvent(InputInfoPtr pInfo,
> struct input_event *ev)
> if (EvdevWheelEmuFilterMotion(pInfo, ev))
> return;
>
> -pEvdev->rel_queued = 1;
> -pEvdev->delta[ev->code] += value;
> -map = pEvdev->axis_map[ev->code];
> -valuator_mask_set(pEvdev->vals, map, value);
> +EvdevInjectRelativeMotion(pEvdev, ev->code, value);
> break;
> }
> }
>
> /**
> + * Inject a relative motion on a valuator axis.
> + **/
> +void
> +EvdevInjectRelativeMotion(EvdevPtr pEvdev, int axis_code, double delta)
> +{
> + int map = pEvdev->axis_map[axis_code];
> +
> + pEvdev->rel_queued = 1;
> + pEvdev->delta[axis_code] += delta;
> + valuator_mask_set_double(pEvdev->vals, map, delta);
> +}
> +
> +/**
> * Take the absolute motion input event and process it accordingly.
> */
> static void
> @@ -896,6 +905,7 @@ EvdevReadInput(InputInfoPtr pInfo)
> }
>
> #define TestBit(bit, array) ((array[(bit) / LONG_BITS]) & (1L << ((bit) %
> LONG_BITS)))
> +#define evdev_SetBit(bit, array) ((array[(bit) / LONG_BITS]) |= (1L <<
> ((bit)
> % LONG_BITS)))
>
> static void
> EvdevPtrCtrlProc(DeviceIn
Re: [PATCH] dix: fix inverted handling of legacy scroll button events
Can you add a reference to the commit that introduced this regression to the
commit message?
On Oct 4, 2011, at 2:55 PM, Max Schwarz wrote:
> This bug led to inverted scrolling axes with legacy drivers that
> do not support smooth scrolling classes.
>
> Signed-off-by: Max Schwarz
> ---
> Applies on Peter's next branch.
>
> dix/getevents.c |9 +
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/dix/getevents.c b/dix/getevents.c
> index ebf2653..97c3937 100644
> --- a/dix/getevents.c
> +++ b/dix/getevents.c
> @@ -1330,21 +1330,22 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr
> pDev, int type,
> double val, adj;
> int axis;
>
> +/* Up is negative on valuators, down positive */
> switch (buttons) {
> case 4:
> -adj = 1.0;
> +adj = -1.0;
> axis = v_scroll_axis;
> break;
> case 5:
> -adj = -1.0;
> +adj = 1.0;
> axis = v_scroll_axis;
> break;
> case 6:
> -adj = 1.0;
> +adj = -1.0;
> axis = h_scroll_axis;
> break;
> case 7:
> -adj = -1.0;
> +adj = 1.0;
> axis = h_scroll_axis;
> break;
> default:
> --
> 1.7.4.1
>
> ___
> 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
>
---
Jeremy Huddleston
Rebuild Sudan
- Board of Directors
- http://www.rebuildsudan.org
Berkeley Foundation for Opportunities in Information Technology
- Advisory Board
- http://www.bfoit.org
___
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
Re: [PATCH] dix: add utility functions for double to/fro FP1616/FP3232 conversion
Reviewed-by: Jeremy Huddleston
Wow, that's all I missed? Not bad for coding in an email client ;)
You might want to replace my "crap" comment with something more descriptive
such as "loss of precision, setting to 0"
On Oct 4, 2011, at 4:39 PM, Peter Hutterer wrote:
> Co-authored by Jeremy Huddleston
> Signed-off-by: Peter Hutterer
> ---
> Jeremy, these are your functions fixed up to pass the tests (a few bitshifts
> where wrong).
> Changes to your version:
> - use trunc instad of (double)(int)(double_value)
> - use rint(trunc()) instead of (int) to silence gcc
> - fix a few wrong bitshifts/masks
> - fix < 0 to < 1 for fabs(frac)
>
> dix/inpututils.c | 68
> include/inpututils.h |6 +++
> test/input.c | 120 ++
> 3 files changed, 194 insertions(+), 0 deletions(-)
>
> diff --git a/dix/inpututils.c b/dix/inpututils.c
> index 582135e..c27e16c 100644
> --- a/dix/inpututils.c
> +++ b/dix/inpututils.c
> @@ -821,3 +821,71 @@ input_option_set_value(InputOption *opt, const char
> *value)
> if (value)
> opt->value = strdup(value);
> }
> +
> +
> +/* FP1616/FP3232 conversion functions */
> +double
> +fp1616_to_double(FP1616 in)
> +{
> +double ret;
> +ret = (double)(in >> 16);
> +ret += ldexp((double)(in & 0x), -16);
> +return ret;
> +}
> +
> +double
> +fp3232_to_double(FP3232 in)
> +{
> +double ret;
> +ret = (double)in.integral;
> +ret += ldexp((double)in.frac, -32);
> +return ret;
> +}
> +
> +
> +FP1616
> +double_to_fp1616(double in)
> +{
> +FP1616 ret;
> +int32_t integral;
> +double frac_f;
> +uint32_t frac_d;
> +
> +integral = (int32_t)in << 16;
> +frac_f = in - trunc(in);
> +
> +if (fabs(frac_f) < 1) {
> + frac_d = rint(trunc(ldexp(frac_f, 16)));
> +} else {
> + /* crap */
> + frac_d = 0;
> +}
> +
> +ret = integral;
> +ret |= frac_d & 0x;
> +return ret;
> +}
> +
> +FP3232
> +double_to_fp3232(double in)
> +{
> +FP3232 ret;
> +int32_t integral;
> +double frac_f;
> +uint32_t frac_d;
> +
> +integral = (int32_t)in;
> +frac_f = in - trunc(in);
> +
> +if (fabs(frac_f) < 1) {
> + frac_d = rint(trunc(ldexp(frac_f,32)));
> +} else {
> + /* crap */
> + frac_d = 0;
> +}
> +
> +ret.integral = integral;
> +ret.frac = frac_d;
> +return ret;
> +}
> +
> diff --git a/include/inpututils.h b/include/inpututils.h
> index 47e242d..2832ed5 100644
> --- a/include/inpututils.h
> +++ b/include/inpututils.h
> @@ -30,6 +30,7 @@
> #define INPUTUTILS_H
>
> #include "input.h"
> +#include
>
> struct _ValuatorMask {
> int8_t last_bit; /* highest bit set in mask */
> @@ -40,4 +41,9 @@ struct _ValuatorMask {
> extern void verify_internal_event(const InternalEvent *ev);
> extern void init_device_event(DeviceEvent *event, DeviceIntPtr dev, Time ms);
>
> +FP3232 double_to_fp3232(double in);
> +FP1616 double_to_fp1616(double in);
> +double fp1616_to_double(FP1616 in);
> +double fp3232_to_double(FP3232 in);
> +
> #endif
> diff --git a/test/input.c b/test/input.c
> index 5fb9a90..05ef3ac 100644
> --- a/test/input.c
> +++ b/test/input.c
> @@ -1476,8 +1476,128 @@ static void input_option_test(void)
> }
>
>
> +static void
> +_test_double_fp16_values(double d)
> +{
> +FP1616 fp16;
> +double re;
> +uint32_t frac;
> +int32_t integral;
> +
> +if (d > 0x7FFF) {
> +printf("Test out of range\n");
> +assert(0);
> +}
> +
> +frac = rint(trunc(ldexp(d - trunc(d), 16)));
> +integral = ((int16_t)d) << 16;
> +
> +fp16 = double_to_fp1616(d);
> +re = fp1616_to_double(fp16);
> +
> +/* printf("FP16: double: %f fp16: %u int: %u frac: %u re:%f\n", d, fp16,
> integral, frac, re); */
> +
> +assert((fp16 & 0x) == integral);
> +assert((fp16 & 0x) == frac);
> +
> +re = fp1616_to_double(fp16);
> +/* since we lose precision, we only do rough range testing */
> +assert(re > d - 0.1);
> +assert(re < d + 0.1);
> +
> +}
> +
> +static void
> +_test_double_fp32_values(double d)
> +{
> +FP3232 fp32;
> +double re;
> +uint32_t frac;
> +int32_t integral;
> +
> +if (d > 0x7FFF) {
> +printf("Test out of range\n");
> +assert(0);
> +}
> +
> +frac = rint(trunc(ldexp(d - trunc(d), 32)));
> +integral = ((int32_t)d);
> +
> +fp32 = double_to_fp3232(d);
> +re = fp3232_to_double(fp32);
> +
> +/* printf("FP32: double: %f fp32: %u.%u int: %u frac: %u re:%f\n", d,
> fp32.integral, fp32.frac, integral, frac, re); */
> +
> +assert(fp32.integral == integral);
> +assert(fp32.frac == frac);
> +
> +re = fp3232_to_double(fp32);
> +/* since we lose precision, we only do rough range testing */
> +assert(re > d - 0.1);
> +assert(re < d + 0.1);
> +}
> +
> +static void
> +dix_double_fp_conversion(void)
> +{
> +long i;
> +printf("Test
Re: [RFC modular] Publish.sh: batch release and autotagging of modules
I haven't reviewed yet, but this seems like a great idea. On Oct 4, 2011, at 12:46 PM, Gaetan Nadon wrote: > Features: > - Navigate the build tree from a given list of modules to release > - Accepts a list in the format produced by build.sh -L > - Tag and version names picked-up from Makefile > - Section name picked-up from module list > - It only release tarballs it has created from the module > - Timely feedback, extensive error checking and final report > - Leave module untouched if already released > - Recover from a failed run with --autoresume > - Verify what will happen with --dry-run > - Generate the announce e-mail > - Update the jhbuild moduleset > > Example: > > util/modular/publish.sh app/xdm lib/libX11-1.1.3 mesa/drm xserver > In this example, libX11-1.1.3 would be at branch 1.1.3 and could be released > in the same batch run with libX11 master. The last subdir name does not > matter. > > Design > --- > The new script is called "publish" for the moment as it may complement or > replace the release script. It is yet to be seen. > > The development process ends with a module whose last commit is a > version bump in the fdo repository. All testing is assumed to have been done. > > The user is not asked to do anything with git tags. No harm done if user tags > the module with the correct tag name. Any non conforming tag will be ignored. > > The srcipt runs 'make dist' to create the tarball. We don't have to prompt > the user for the tar name, the version number or the section name. > > The "section" is technically the first subdir down from the script invocation > directory. For all but a few, it mathces the subdir on host /svr where the > tarballs are uploaded. There may be zero or one subdir below the "section". > Exceptions such as mesa/drm have custom code to handle. > > Interface > - > Usage: publish.sh [options] section[/module]... > > Section: > app|data|doc|driver|font|lib|mesa|pixman|proto|util|xcb| > xkeyboard-config|xserver > > Module: > One optional subdirectory (name does not matter) for a git module. > > Options: > --autoresume Resume publishing modules from last attempt. Use > --dry-run Does everything except tagging and uploading tarballs > --force Force overwritting an existing release > --help Display this help and exit successfully > --modfile Publish the section/modules specified in > --moduleset The jhbuild moduleset full pathname to be updated > --no-quit Do not quit after error; just print error message > --userUsername of your fdo account if not configured in ssh > > Environment variables defined by the "make" program and used by publish.sh: > MAKEThe name of the make command [make] > MAKEFLAGS: Options to pass to all $(MAKE) invocations > > Usage Scenarios > > Due to a change to the m4 macro, all font packages need to released. > >util/modular/build.sh -L | grep font/ > myList.txt >util/modular/publish.sh --autoresume resume.txt --modfile myList.txt > > A developer is asking a buddy to relase a few protocols and libraries. > He sends the list in an e-mail. Once all is done on disk: > >edit myList.txt (or save from e-mail) >util/modular/publish.sh --no-quit --modfile myList.txt > > A single app needs to be released for an important bug fix > >util/modular/publish.sh app/xdm > > Supports libdrm and xkeybboard-config: > >util/modular/publish.sh xkeyboard-config mesa/drm > > Signed-off-by: Gaetan Nadon > --- > > Might as well get comments now before I do detailed testing. > > Questions/issues for reviewers: > > Should pgp signature be included by default for taggging? > > Anyone seen a tag called "initial"? as in: case "$tag_previous" in initial) > > The name of the remote repo being tracked is obtained from git-config. > It cannot be suppiled on the cmd line as it can vary by module. > > No local changes allowed and no override permitted. The script only publishes > the tarballs it creates from a clean module. Safety first. > Just clone the repo into a different subdir in the same section to leave your > development local repo untouched. > > readlink (for jh module set) is not portable (missing on Solaris) > and has not been retained. Replacement? Platform check? > > The private versioning scheme for intel video driver has not been retained. > http://cgit.freedesktop.org/xorg/util/modular/commit/release.sh?id=520f454a0e57ba4d9a411fac3c17dc096297c66e > > > publish.sh | 665 > 1 files changed, 665 insertions(+), 0 deletions(-) > create mode 100755 publish.sh > > diff --git a/publish.sh b/publish.sh > new file mode 100755 > index 000..5ff7454 > --- /dev/null > +++ b/publish.sh > @@ -0,0 +1,665 @@ > +#!/bin/sh > +# > +#Creates and upload a git module tarball > +# > +# Note on portability: > +# This script is intended to run on any platfo
Re: [PATCH] dix: add utility functions for double to/fro FP1616/FP3232 conversion
On Tue, Oct 04, 2011 at 06:02:21PM -0700, Jeremy Huddleston wrote:
> Reviewed-by: Jeremy Huddleston
>
> Wow, that's all I missed? Not bad for coding in an email client ;)
>
> You might want to replace my "crap" comment with something more
> descriptive such as "loss of precision, setting to 0"
I thought it was quite expressive as-is but I will amend :)
I wonder if we need this path at all though. after all, if d-trunc(d) starts
giving us values outside of 0..1 we have other problems.
Also, this needs a follow-up patch anyway, I completely forgot to test
negative numbers.
Cheers,
Peter
> On Oct 4, 2011, at 4:39 PM, Peter Hutterer wrote:
>
> > Co-authored by Jeremy Huddleston
> > Signed-off-by: Peter Hutterer
> > ---
> > Jeremy, these are your functions fixed up to pass the tests (a few bitshifts
> > where wrong).
> > Changes to your version:
> > - use trunc instad of (double)(int)(double_value)
> > - use rint(trunc()) instead of (int) to silence gcc
> > - fix a few wrong bitshifts/masks
> > - fix < 0 to < 1 for fabs(frac)
> >
> > dix/inpututils.c | 68
> > include/inpututils.h |6 +++
> > test/input.c | 120
> > ++
> > 3 files changed, 194 insertions(+), 0 deletions(-)
> >
> > diff --git a/dix/inpututils.c b/dix/inpututils.c
> > index 582135e..c27e16c 100644
> > --- a/dix/inpututils.c
> > +++ b/dix/inpututils.c
> > @@ -821,3 +821,71 @@ input_option_set_value(InputOption *opt, const char
> > *value)
> > if (value)
> > opt->value = strdup(value);
> > }
> > +
> > +
> > +/* FP1616/FP3232 conversion functions */
> > +double
> > +fp1616_to_double(FP1616 in)
> > +{
> > +double ret;
> > +ret = (double)(in >> 16);
> > +ret += ldexp((double)(in & 0x), -16);
> > +return ret;
> > +}
> > +
> > +double
> > +fp3232_to_double(FP3232 in)
> > +{
> > +double ret;
> > +ret = (double)in.integral;
> > +ret += ldexp((double)in.frac, -32);
> > +return ret;
> > +}
> > +
> > +
> > +FP1616
> > +double_to_fp1616(double in)
> > +{
> > +FP1616 ret;
> > +int32_t integral;
> > +double frac_f;
> > +uint32_t frac_d;
> > +
> > +integral = (int32_t)in << 16;
> > +frac_f = in - trunc(in);
> > +
> > +if (fabs(frac_f) < 1) {
> > + frac_d = rint(trunc(ldexp(frac_f, 16)));
> > +} else {
> > + /* crap */
> > + frac_d = 0;
> > +}
> > +
> > +ret = integral;
> > +ret |= frac_d & 0x;
> > +return ret;
> > +}
> > +
> > +FP3232
> > +double_to_fp3232(double in)
> > +{
> > +FP3232 ret;
> > +int32_t integral;
> > +double frac_f;
> > +uint32_t frac_d;
> > +
> > +integral = (int32_t)in;
> > +frac_f = in - trunc(in);
> > +
> > +if (fabs(frac_f) < 1) {
> > + frac_d = rint(trunc(ldexp(frac_f,32)));
> > +} else {
> > + /* crap */
> > + frac_d = 0;
> > +}
> > +
> > +ret.integral = integral;
> > +ret.frac = frac_d;
> > +return ret;
> > +}
> > +
> > diff --git a/include/inpututils.h b/include/inpututils.h
> > index 47e242d..2832ed5 100644
> > --- a/include/inpututils.h
> > +++ b/include/inpututils.h
> > @@ -30,6 +30,7 @@
> > #define INPUTUTILS_H
> >
> > #include "input.h"
> > +#include
> >
> > struct _ValuatorMask {
> > int8_t last_bit; /* highest bit set in mask */
> > @@ -40,4 +41,9 @@ struct _ValuatorMask {
> > extern void verify_internal_event(const InternalEvent *ev);
> > extern void init_device_event(DeviceEvent *event, DeviceIntPtr dev, Time
> > ms);
> >
> > +FP3232 double_to_fp3232(double in);
> > +FP1616 double_to_fp1616(double in);
> > +double fp1616_to_double(FP1616 in);
> > +double fp3232_to_double(FP3232 in);
> > +
> > #endif
> > diff --git a/test/input.c b/test/input.c
> > index 5fb9a90..05ef3ac 100644
> > --- a/test/input.c
> > +++ b/test/input.c
> > @@ -1476,8 +1476,128 @@ static void input_option_test(void)
> > }
> >
> >
> > +static void
> > +_test_double_fp16_values(double d)
> > +{
> > +FP1616 fp16;
> > +double re;
> > +uint32_t frac;
> > +int32_t integral;
> > +
> > +if (d > 0x7FFF) {
> > +printf("Test out of range\n");
> > +assert(0);
> > +}
> > +
> > +frac = rint(trunc(ldexp(d - trunc(d), 16)));
> > +integral = ((int16_t)d) << 16;
> > +
> > +fp16 = double_to_fp1616(d);
> > +re = fp1616_to_double(fp16);
> > +
> > +/* printf("FP16: double: %f fp16: %u int: %u frac: %u re:%f\n", d,
> > fp16, integral, frac, re); */
> > +
> > +assert((fp16 & 0x) == integral);
> > +assert((fp16 & 0x) == frac);
> > +
> > +re = fp1616_to_double(fp16);
> > +/* since we lose precision, we only do rough range testing */
> > +assert(re > d - 0.1);
> > +assert(re < d + 0.1);
> > +
> > +}
> > +
> > +static void
> > +_test_double_fp32_values(double d)
> > +{
> > +FP3232 fp32;
> > +double re;
> > +uint32_t frac;
> > +int32_t integral;
> > +
> > +if (d > 0x7F
[PATCH] dix: mark motion events as emulated if we're scrolling from button press
The protocol requires that the emulated event is marked as such. So if a
driver with smooth scrolling axis sends legacy button events, the motion
event must be marked as emulated.
Pass the real type to emulate_scroll_button_events and create the events
accordingly. For real button press or relase events, only that event must be
generated since a release event will follow or a press event has already
occured, respectively. (This fixes a bug where we'd get two release events
for each legacy button event)
Signed-off-by: Peter Hutterer
---
dix/getevents.c | 31 ++-
1 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/dix/getevents.c b/dix/getevents.c
index adf945f..c55e1a0 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -1294,6 +1294,7 @@ fill_pointer_events(InternalEvent *events, DeviceIntPtr
pDev, int type,
*
* @param events The pointer to the event list to fill the events
* @param dev The device to generate the events for
+ * @param type The real type of the event
* @param axis The axis number to generate events for
* @param mask State before this event in absolute coords
* @param[in,out] last Last scroll state posted in absolute coords (modified
@@ -1305,6 +1306,7 @@ fill_pointer_events(InternalEvent *events, DeviceIntPtr
pDev, int type,
static int
emulate_scroll_button_events(InternalEvent *events,
DeviceIntPtr dev,
+ int type,
int axis,
const ValuatorMask *mask,
ValuatorMask *last,
@@ -1317,6 +1319,7 @@ emulate_scroll_button_events(InternalEvent *events,
int num_events = 0;
double total;
int b;
+int flags = 0;
if (dev->valuator->axes[axis].scroll.type == SCROLL_TYPE_NONE)
return 0;
@@ -1327,6 +1330,9 @@ emulate_scroll_button_events(InternalEvent *events,
ax = &dev->valuator->axes[axis];
incr = ax->scroll.increment;
+if (type != ButtonPress && type != ButtonRelease)
+flags |= POINTER_EMULATED;
+
if (!valuator_mask_isset(last, axis))
valuator_mask_set_double(last, axis, 0);
@@ -1354,14 +1360,19 @@ emulate_scroll_button_events(InternalEvent *events,
*/
if (num_events + 4 < max_events)
{
-nev_tmp = fill_pointer_events(events, dev, ButtonPress, b, ms,
- POINTER_EMULATED, NULL);
-events += nev_tmp;
-num_events += nev_tmp;
-nev_tmp = fill_pointer_events(events, dev, ButtonRelease, b, ms,
- POINTER_EMULATED, NULL);
-events += nev_tmp;
-num_events += nev_tmp;
+if (type != ButtonRelease) {
+nev_tmp = fill_pointer_events(events, dev, ButtonPress, b, ms,
+ flags, NULL);
+events += nev_tmp;
+num_events += nev_tmp;
+}
+if (type != ButtonPress)
+{
+nev_tmp = fill_pointer_events(events, dev, ButtonRelease, b,
ms,
+ flags, NULL);
+events += nev_tmp;
+num_events += nev_tmp;
+}
}
}
@@ -1406,6 +1417,7 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr
pDev, int type,
ValuatorMask mask;
ValuatorMask scroll;
int i;
+int realtype = type;
/* refuse events from disabled devices */
if (!pDev->enabled)
@@ -1458,6 +1470,7 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr
pDev, int type,
valuator_mask_set_double(&mask, axis, val);
type = MotionNotify;
buttons = 0;
+flags |= POINTER_EMULATED;
}
}
@@ -1477,7 +1490,7 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr
pDev, int type,
valuator_mask_set_double(&scroll, i, pDev->last.valuators[i]);
-nev_tmp = emulate_scroll_button_events(events, pDev, i, &scroll,
+nev_tmp = emulate_scroll_button_events(events, pDev, realtype, i,
&scroll,
pDev->last.scroll, ms,
GetMaximumEventsNum() -
num_events);
events += nev_tmp;
--
1.7.6.4
___
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
Re: [PATCH] dix: fix inverted handling of legacy scroll button events
On Tue, Oct 04, 2011 at 10:06:08PM +0200, Max Schwarz wrote:
> This bug led to inverted scrolling axes with legacy drivers that
> do not support smooth scrolling classes.
>
> Signed-off-by: Max Schwarz
merged, thanks. though I've amended the commit message, this can only be
triggered if a driver does support smooth scrolling but sends legacy events
nonetheless (which is why I hadn't found this earlier).
Cheers,
Peter
> ---
> dix/getevents.c |9 +
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/dix/getevents.c b/dix/getevents.c
> index ebf2653..97c3937 100644
> --- a/dix/getevents.c
> +++ b/dix/getevents.c
> @@ -1330,21 +1330,22 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr
> pDev, int type,
> double val, adj;
> int axis;
>
> +/* Up is negative on valuators, down positive */
> switch (buttons) {
> case 4:
> -adj = 1.0;
> +adj = -1.0;
> axis = v_scroll_axis;
> break;
> case 5:
> -adj = -1.0;
> +adj = 1.0;
> axis = v_scroll_axis;
> break;
> case 6:
> -adj = 1.0;
> +adj = -1.0;
> axis = h_scroll_axis;
> break;
> case 7:
> -adj = -1.0;
> +adj = 1.0;
> axis = h_scroll_axis;
> break;
> default:
> --
> 1.7.4.1
>
>
___
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
Re: [PATCH] fix doPolyText use-after-free issue
Thanks, I've pulled this into my tree, and it will be in my next pull request
to master.
On Oct 4, 2011, at 12:48 AM, Alan Hourihane wrote:
> Attached.
>
> Thanks Jeremy. What's happening to the 1.10.x branch now ? Can this be
> nominated for that too ?
>
> Alan.
>
> On 09/28/11 07:46, Jeremy Huddleston wrote:
>> I missed this point at first. The context is that in 'bail', c is accessed
>> and expected to be the old value.
>>
>> Candidate for 1.11-branch
>>
>> Reviewed-by: Jeremy Huddleston
>>
>> I think something is wrong with your mailer (or maybe mine). I was unable
>> to git-am this patch. Can you please resend it as an attachment, and I'll
>> git-am it into my tree.
>>
>> --Jeremy
>>
>> On Sep 27, 2011, at 6:51 AM, Alan Hourihane wrote:
>>
>>> dixfonts: Don't overwrite local c variable until new_closure is safely
>>> initialized.
>>>
>>> Signed-off-by: Alan Hourihane
>>>
>>> diff --git a/dix/dixfonts.c b/dix/dixfonts.c
>>> index fbac124..d2bcb84 100644
>>> --- a/dix/dixfonts.c
>>> +++ b/dix/dixfonts.c
>>> @@ -1302,31 +1302,30 @@ doPolyText(ClientPtr client, PTclosurePtr c)
>>>goto bail;
>>>}
>>>*new_closure = *c;
>>> -c = new_closure;
>>>
>>> -len = c->endReq - c->pElt;
>>> -c->data = malloc(len);
>>> -if (!c->data)
>>> +len = new_closure->endReq - new_closure->pElt;
>>> +new_closure->data = malloc(len);
>>> +if (!new_closure->data)
>>>{
>>> -free(c);
>>> +free(new_closure);
>>>err = BadAlloc;
>>>goto bail;
>>>}
>>> -memmove(c->data, c->pElt, len);
>>> -c->pElt = c->data;
>>> -c->endReq = c->pElt + len;
>>> +memmove(new_closure->data, new_closure->pElt, len);
>>> +new_closure->pElt = new_closure->data;
>>> +new_closure->endReq = new_closure->pElt + len;
>>>
>>>/* Step 2 */
>>>
>>> -pGC = GetScratchGC(c->pGC->depth, c->pGC->pScreen);
>>> +pGC = GetScratchGC(new_closure->pGC->depth,
>>> new_closure->pGC->pScreen);
>>>if (!pGC)
>>>{
>>> -free(c->data);
>>> -free(c);
>>> +free(new_closure->data);
>>> +free(new_closure);
>>>err = BadAlloc;
>>>goto bail;
>>>}
>>> -if ((err = CopyGC(c->pGC, pGC, GCFunction |
>>> +if ((err = CopyGC(new_closure->pGC, pGC, GCFunction |
>>> GCPlaneMask | GCForeground |
>>> GCBackground | GCFillStyle |
>>> GCTile | GCStipple |
>>> @@ -1337,15 +1336,16 @@ doPolyText(ClientPtr client, PTclosurePtr c)
>>> Success)
>>>{
>>>FreeScratchGC(pGC);
>>> -free(c->data);
>>> -free(c);
>>> +free(new_closure->data);
>>> +free(new_closure);
>>>err = BadAlloc;
>>>goto bail;
>>>}
>>> +c = new_closure;
>>>origGC = c->pGC;
>>>c->pGC = pGC;
>>>ValidateGC(c->pDraw, c->pGC);
>>> -
>>> +
>>>ClientSleep(client, (ClientSleepProcPtr)doPolyText, c);
>>>
>>>/* Set up to perform steps 3 and 4 */
>>>
>>> ___
>>> 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
>>>
>
>
---
Jeremy Huddleston
Rebuild Sudan
- Board of Directors
- http://www.rebuildsudan.org
Berkeley Foundation for Opportunities in Information Technology
- Advisory Board
- http://www.bfoit.org
___
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
Re: [PATCH xserver/hw/xfree86/modes/xf86Crtc.c] trivial memory leak
reviewed and pulled into my tree for my next pull request.
On Sep 17, 2011, at 9:55 AM, v...@picaros.org wrote:
> Anyone willing to review this triviality ? The code is included below.
>
> This patch fixes a memory leak in xf86CrtcCreate(). It frees the
> crtc->gamma_red buffer when a quit on error occurs.
>
> xf86CrtcPtr
> xf86CrtcCreate (ScrnInfoPtr scrn,
> const xf86CrtcFuncsRec *funcs)
> <...>
>
>crtc->gamma_size = 256;
> -> crtc->gamma_red = malloc(3 * crtc->gamma_size * sizeof (CARD16));
>if (!crtc->gamma_red) {
> free(crtc);
> return NULL;
>}
>crtc->gamma_green = crtc->gamma_red + crtc->gamma_size;
>crtc->gamma_blue = crtc->gamma_green + crtc->gamma_size;
>
>if (xf86_config->crtc)
> crtcs = realloc(xf86_config->crtc,
> (xf86_config->num_crtc + 1) * sizeof (xf86CrtcPtr));
>else
> crtcs = malloc((xf86_config->num_crtc + 1) * sizeof (xf86CrtcPtr));
>if (!crtcs)
>{
> ->free(crtc);
> ->return NULL;
>}
>
> Signed-off-by: Servaas Vandenberghe
> diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
> index c2814d4..74c8d66 100644
> --- a/hw/xfree86/modes/xf86Crtc.c
> +++ b/hw/xfree86/modes/xf86Crtc.c
> @@ -133,6 +133,7 @@ xf86CrtcCreate (ScrnInfoPtr scrn,
> crtcs = malloc((xf86_config->num_crtc + 1) * sizeof (xf86CrtcPtr));
> if (!crtcs)
> {
> + free(crtc->gamma_red);
> free(crtc);
> return NULL;
> }
> ___
> 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
>
---
Jeremy Huddleston
Rebuild Sudan
- Board of Directors
- http://www.rebuildsudan.org
Berkeley Foundation for Opportunities in Information Technology
- Advisory Board
- http://www.bfoit.org
___
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
Re: [PATCH] mkfontscale: Support FontForge weight designations.
reviewed and pushed
d429321..8ee3b3f master -> master
On Oct 3, 2011, at 12:52 PM, Maxim Iorsh wrote:
> Fontforge uses 'ExtraLight' and 'Heavy' weights in Type 1 fonts, which
> should be understood by mkfontscale. Other FontForge designations are
> already addressed.
>
> Signed-off-by: Maxim Iorsh
> ---
> mkfontscale.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/mkfontscale.c b/mkfontscale.c
> index 31553cb..49bbe77 100644
> --- a/mkfontscale.c
> +++ b/mkfontscale.c
> @@ -426,6 +426,8 @@ t1Weight(char *weight)
> return NULL;
> if(strcmp(weight, "Thin") == 0)
> return "thin";
> +if(strcmp(weight, "ExtraLight") == 0) /* FontForge uses this for 200*/
> +return "extralight";
> if(strcmp(weight, "Light") == 0)
> return "light";
> if(strcmp(weight, "Regular") == 0)
> @@ -446,6 +448,8 @@ t1Weight(char *weight)
> return "semibold";
> else if(strcmp(weight, "Bold") == 0)
> return "bold";
> +else if(strcmp(weight, "Heavy") == 0) /* FontForge uses this for 800*/
> +return "extrabold";
> else if(strcmp(weight, "Black") == 0)
> return "black";
> else {
> --
> 1.7.3.4
>
> ___
> 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
>
---
Jeremy Huddleston
Rebuild Sudan
- Board of Directors
- http://www.rebuildsudan.org
Berkeley Foundation for Opportunities in Information Technology
- Advisory Board
- http://www.bfoit.org
___
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
Re: [PATCH evdev, v2] Support smooth scrolling on wheel emulation
On Tue, Oct 04, 2011 at 09:53:56PM +0200, Max Schwarz wrote:
> This adds support for the new smooth-scrolling valuator system to
> the wheel emulation code.
>
> Caveats:
> - Enabling wheel emulation at runtime does not work if the device
>does not provide the necessary axes already.
you could make the support compiled in, but not compiled _out_. so even if
you HAVE_SMOOTH_SCROLLING, the old bits are ready to go when enabled.
if no smooth scrolling axis is otherwise present on the device, just post
button events as previously.
> - Horizontal scrolling is always reported on the REL_HWHEEL axis,
>ignoring a REL_DIAL axis present in hardware.
REL_DIAL is set up as vertical axis by default anyway.
>
> Signed-off-by: Max Schwarz
> ---
> Resend, my E-Mail client ate the patch...
>
> src/emuWheel.c | 19 ++-
> src/evdev.c| 34 +++---
> src/evdev.h|4 +++-
> 3 files changed, 48 insertions(+), 9 deletions(-)
>
> diff --git a/src/emuWheel.c b/src/emuWheel.c
> index ae894fa..0439a5b 100644
> --- a/src/emuWheel.c
> +++ b/src/emuWheel.c
> @@ -167,9 +167,13 @@ static int
> EvdevWheelEmuInertia(InputInfoPtr pInfo, WheelAxisPtr axis, int value)
> {
> EvdevPtr pEvdev = (EvdevPtr)pInfo->private;
> +int rc = 0;
> +#ifndef HAVE_SMOOTH_SCROLLING
> int button;
> int inertia;
> -int rc = 0;
> +#else
> + double v;
> +#endif
>
> /* if this axis has not been configured, just eat the motion */
> if (!axis->up_button)
> @@ -177,6 +181,7 @@ EvdevWheelEmuInertia(InputInfoPtr pInfo, WheelAxisPtr
> axis, int value)
>
> axis->traveled_distance += value;
>
> +#ifndef HAVE_SMOOTH_SCROLLING
> if (axis->traveled_distance < 0) {
> button = axis->up_button;
> inertia = -pEvdev->emulateWheel.inertia;
> @@ -192,6 +197,14 @@ EvdevWheelEmuInertia(InputInfoPtr pInfo, WheelAxisPtr
> axis, int value)
> rc++;
> }
> return rc;
> +#else
> +/* Inject relative valuator delta */
> +v = -((double)axis->traveled_distance) / pEvdev->emulateWheel.inertia;
> +EvdevInjectRelativeMotion(pEvdev, axis->code, v);
> +axis->traveled_distance = 0;
> +xf86IDrvMsg(pInfo, X_ERROR, "rel motion: %f\n", v);
this should be removed in the final version
> +return 1;
> +#endif
> }
>
> /* Handle button mapping here to avoid code duplication,
> @@ -322,6 +335,10 @@ EvdevWheelEmuPreInit(InputInfoPtr pInfo)
> pEvdev->emulateWheel.X.traveled_distance = 0;
> pEvdev->emulateWheel.Y.traveled_distance = 0;
>
> +/* Used to inject smooth scrolling events */
> +pEvdev->emulateWheel.X.code = REL_HWHEEL;
> +pEvdev->emulateWheel.Y.code = REL_WHEEL;
> +
> xf86IDrvMsg(pInfo, X_CONFIG,
> "EmulateWheelButton: %d, "
> "EmulateWheelInertia: %d, "
> diff --git a/src/evdev.c b/src/evdev.c
> index 2281206..9559758 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -362,7 +362,7 @@ EvdevProcessValuators(InputInfoPtr pInfo)
> {
> int tmp;
> EvdevPtr pEvdev = pInfo->private;
> -int *delta = pEvdev->delta;
> +double *delta = pEvdev->delta;
>
> /* convert to relative motion for touchpads */
> if (pEvdev->abs_queued && (pEvdev->flags & EVDEV_RELATIVE_MODE)) {
> @@ -413,7 +413,7 @@ EvdevProcessValuators(InputInfoPtr pInfo)
> {
> int map = pEvdev->axis_map[i];
> if (pEvdev->delta[i] && map != -1)
> -valuator_mask_set(pEvdev->vals, map, pEvdev->delta[i]);
> +valuator_mask_set_double(pEvdev->vals, map, pEvdev-
> >delta[i]);
> }
> }
> /*
> @@ -586,7 +586,6 @@ EvdevProcessRelativeMotionEvent(InputInfoPtr pInfo,
> struct
> input_event *ev)
> {
> int value;
> EvdevPtr pEvdev = pInfo->private;
> -int map;
>
> /* Get the signed value, earlier kernels had this as unsigned */
> value = ev->value;
> @@ -618,15 +617,25 @@ EvdevProcessRelativeMotionEvent(InputInfoPtr pInfo,
> struct input_event *ev)
> if (EvdevWheelEmuFilterMotion(pInfo, ev))
> return;
>
> -pEvdev->rel_queued = 1;
> -pEvdev->delta[ev->code] += value;
> -map = pEvdev->axis_map[ev->code];
> -valuator_mask_set(pEvdev->vals, map, value);
> +EvdevInjectRelativeMotion(pEvdev, ev->code, value);
> break;
> }
> }
>
> /**
> + * Inject a relative motion on a valuator axis.
> + **/
> +void
> +EvdevInjectRelativeMotion(EvdevPtr pEvdev, int axis_code, double delta)
> +{
> + int map = pEvdev->axis_map[axis_code];
> +
> + pEvdev->rel_queued = 1;
> + pEvdev->delta[axis_code] += delta;
> + valuator_mask_set_double(pEvdev->vals, map, delta);
> +}
> +
> +/**
> * Take the absolute motion input event and process it accordingly.
> */
> static void
> @@ -896,6 +905,7 @@ EvdevReadInput(InputInfoPtr pInfo)
> }
>
> #define TestBit(bit, array) ((
[PULL] pot pouri
The following changes since commit 6378d0233d21088b6429755627b4253859892c72: Merge remote-tracking branch 'herrb/master' (2011-10-03 13:56:06 -0700) are available in the git repository at: git://people.freedesktop.org/~jeremyhu/xserver for-keith Alan Hourihane (1): dixfonts: Don't overwrite local c variable until new_closure is safely initialized. Jeremy Huddleston (1): XQuartz: pbproxy: Add missing AM_OBJCFLAGS Kirill Elagin (1): Fix server crash due to invalid images v...@picaros.org (1): Fix a rare memory leak dix/dixfonts.c | 30 +++--- fb/fbpict.c|4 +++- hw/xfree86/modes/xf86Crtc.c|1 + hw/xquartz/pbproxy/Makefile.am |1 + 4 files changed, 20 insertions(+), 16 deletions(-) --- Jeremy Huddleston Rebuild Sudan - Board of Directors - http://www.rebuildsudan.org Berkeley Foundation for Opportunities in Information Technology - Advisory Board - http://www.bfoit.org ___ 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
Re: [PULL] pot pouri
On Tue, 4 Oct 2011 22:13:49 -0700, Jeremy Huddleston wrote: > Alan Hourihane (1): > dixfonts: Don't overwrite local c variable until new_closure is safely > initialized. > > Jeremy Huddleston (1): > XQuartz: pbproxy: Add missing AM_OBJCFLAGS > > Kirill Elagin (1): > Fix server crash due to invalid images > > v...@picaros.org (1): > Fix a rare memory leak Merged. 6378d02..fae7ed6 master -> master -- keith.pack...@intel.com pgpF8xc8SlaUL.pgp Description: PGP signature ___ 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
[PATCH:libpciaccess] Solaris: Give better error on realloc failure
commit a18460b385ae03 converted from a fixed maximum number of devices
to dynamically growing the list via realloc, but didn't update the
error message shown on failure.
Signed-off-by: Alan Coopersmith
---
src/solx_devfs.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/solx_devfs.c b/src/solx_devfs.c
index d47a846..ea91479 100644
--- a/src/solx_devfs.c
+++ b/src/solx_devfs.c
@@ -454,8 +454,9 @@ probe_dev(nexus_t *nexus, pcitool_reg_t *prg_p,
probe_info_t *pinfo)
new_num_elems * sizeof (struct pci_device_private));
if (new_devs == NULL) {
(void) fprintf(stderr,
- "Maximum number of PCI devices found,"
- " discarding additional devices\n");
+ "Error allocating memory for PCI devices:"
+ " %s\n discarding additional devices\n",
+ strerror(errno));
return (rval);
}
(void) memset(&new_devs[pinfo->num_devices], 0,
--
1.7.3.2
___
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
