[PATCH:xkill] Use strcasecmp instead of a tolower loop & strcmp
Signed-off-by: Alan Coopersmith
---
xkill.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/xkill.c b/xkill.c
index 32cb0cc..2db5847 100644
--- a/xkill.c
+++ b/xkill.c
@@ -55,7 +55,7 @@ static char *ProgramName;
#define SelectButtonAny (-1)
#define SelectButtonFirst (-2)
-static int parse_button ( char *s, int *buttonp );
+static int parse_button ( const char *s, int *buttonp );
static XID get_window_id ( Display *dpy, int screen, int button, const char
*msg );
static int catch_window_errors ( Display *dpy, XErrorEvent *ev );
static int kill_all_windows ( Display *dpy, int screenno, Bool top );
@@ -240,22 +240,11 @@ main(int argc, char *argv[])
}
static int
-parse_button(char *s, int *buttonp)
+parse_button(const char *s, int *buttonp)
{
-register char *cp;
+const char *cp;
-/* lower case name */
-for (cp = s; *cp; cp++) {
- if (isascii (*cp) && isupper (*cp)) {
-#ifdef _tolower
- *cp = (char) _tolower (*cp);
-#else
- *cp = (char) tolower (*cp);
-#endif /* _tolower */
- }
-}
-
-if (strcmp (s, "any") == 0) {
+if (strcasecmp (s, "any") == 0) {
*buttonp = SelectButtonAny;
return (1);
}
--
1.7.9.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
Re: [PATCH] composite: Don't bother copying the pixmap for ForgetGravity windows (v2)
The compositor sync protocol helps that tremendously, where the client
actually tells the compositor when it can start to use the new pixmap.
I tested with xcompmgr and nautilus, and couldn't see any flickering,
which tells me that clients are actually plenty fast enough already.
But yeah, you might see flickering in a worst case scenario. I'd argue
that isn't much better than the current NorthWestGravity behavior
where we lop off the bottom/right edge of the window. There's no true
way to solve this properly besides a Wayland-approach where the client
just presents the compositor a correctly-sized, finished pixmap.
On Thu, Apr 23, 2015 at 2:13 PM, Aaron Plattner wrote:
> Does this cause flickering when resizing windows and the compositor reads
> the new window pixmap before the app has a chance to respond to the events?
>
>
> On 04/23/2015 01:24 PM, Jasper St. Pierre wrote:
>>
>> If a window has ForgetGravity in its bitGravity, that very likely
>> means it will repaint on the ConfigureNotify / Expose event, and thus
>> we don't have to copy the old pixmap into the new pixmap, we can simply
>> leave it blank.
>>
>> Preventing this copy is super simple to do and a big win on small
>> devices where these blits can be expensive.
>>
>> A better approach would be to actually obey BitGravity correctly rather
>> than assume NorthWestGravity always, but this is a big speedup for the
>> common case.
>>
>> v2: Check all subwindows to make sure they are also ForgetGravity
>>
>> Cc: Adam Jackson
>> Signed-off-by: Jasper St. Pierre
>> ---
>> composite/compalloc.c | 109
>> +-
>> 1 file changed, 63 insertions(+), 46 deletions(-)
>>
>> diff --git a/composite/compalloc.c b/composite/compalloc.c
>> index 8daded0..40bf873 100644
>> --- a/composite/compalloc.c
>> +++ b/composite/compalloc.c
>> @@ -526,6 +526,21 @@ compUnredirectOneSubwindow(WindowPtr pParent,
>> WindowPtr pWin)
>> return Success;
>> }
>>
>> +static Bool
>> +needsPixmapCopy(WindowPtr pWin)
>> +{
>> +WindowPtr pChild;
>> +
>> +if (pWin->bitGravity != ForgetGravity)
>> +return TRUE;
>> +
>> +for (pChild = pWin->firstChild; pChild; pChild = pChild->nextSib)
>> +if (needsPixmapCopy(pChild))
>> +return TRUE;
>> +
>> +return FALSE;
>> +}
>> +
>> static PixmapPtr
>> compNewPixmap(WindowPtr pWin, int x, int y, int w, int h)
>> {
>> @@ -542,54 +557,56 @@ compNewPixmap(WindowPtr pWin, int x, int y, int w,
>> int h)
>> pPixmap->screen_x = x;
>> pPixmap->screen_y = y;
>>
>> -if (pParent->drawable.depth == pWin->drawable.depth) {
>> -GCPtr pGC = GetScratchGC(pWin->drawable.depth, pScreen);
>> -
>> -if (pGC) {
>> -ChangeGCVal val;
>> -
>> -val.val = IncludeInferiors;
>> -ChangeGC(NullClient, pGC, GCSubwindowMode, &val);
>> -ValidateGC(&pPixmap->drawable, pGC);
>> -(*pGC->ops->CopyArea) (&pParent->drawable,
>> - &pPixmap->drawable,
>> - pGC,
>> - x - pParent->drawable.x,
>> - y - pParent->drawable.y, w, h, 0, 0);
>> -FreeScratchGC(pGC);
>> +if (needsPixmapCopy(pWin)) {
>> +if (pParent->drawable.depth == pWin->drawable.depth) {
>> +GCPtr pGC = GetScratchGC(pWin->drawable.depth, pScreen);
>> +
>> +if (pGC) {
>> +ChangeGCVal val;
>> +
>> +val.val = IncludeInferiors;
>> +ChangeGC(NullClient, pGC, GCSubwindowMode, &val);
>> +ValidateGC(&pPixmap->drawable, pGC);
>> +(*pGC->ops->CopyArea) (&pParent->drawable,
>> + &pPixmap->drawable,
>> + pGC,
>> + x - pParent->drawable.x,
>> + y - pParent->drawable.y, w, h, 0,
>> 0);
>> +FreeScratchGC(pGC);
>> +}
>> }
>> -}
>> -else {
>> -PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
>> -PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
>> -XID inferiors = IncludeInferiors;
>> -int error;
>> -
>> -PicturePtr pSrcPicture = CreatePicture(None,
>> - &pParent->drawable,
>> - pSrcFormat,
>> - CPSubwindowMode,
>> - &inferiors,
>> - serverClient, &error);
>> -
>> -PicturePtr pDstPicture = CreatePicture(None,
>> - &pPixmap->drawable,
>> - pDstFormat,
>> - 0, 0,
>> -
Re: [PATCH] composite: Don't bother copying the pixmap for ForgetGravity windows (v2)
Does this cause flickering when resizing windows and the compositor
reads the new window pixmap before the app has a chance to respond to
the events?
On 04/23/2015 01:24 PM, Jasper St. Pierre wrote:
If a window has ForgetGravity in its bitGravity, that very likely
means it will repaint on the ConfigureNotify / Expose event, and thus
we don't have to copy the old pixmap into the new pixmap, we can simply
leave it blank.
Preventing this copy is super simple to do and a big win on small
devices where these blits can be expensive.
A better approach would be to actually obey BitGravity correctly rather
than assume NorthWestGravity always, but this is a big speedup for the
common case.
v2: Check all subwindows to make sure they are also ForgetGravity
Cc: Adam Jackson
Signed-off-by: Jasper St. Pierre
---
composite/compalloc.c | 109 +-
1 file changed, 63 insertions(+), 46 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index 8daded0..40bf873 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -526,6 +526,21 @@ compUnredirectOneSubwindow(WindowPtr pParent, WindowPtr
pWin)
return Success;
}
+static Bool
+needsPixmapCopy(WindowPtr pWin)
+{
+WindowPtr pChild;
+
+if (pWin->bitGravity != ForgetGravity)
+return TRUE;
+
+for (pChild = pWin->firstChild; pChild; pChild = pChild->nextSib)
+if (needsPixmapCopy(pChild))
+return TRUE;
+
+return FALSE;
+}
+
static PixmapPtr
compNewPixmap(WindowPtr pWin, int x, int y, int w, int h)
{
@@ -542,54 +557,56 @@ compNewPixmap(WindowPtr pWin, int x, int y, int w, int h)
pPixmap->screen_x = x;
pPixmap->screen_y = y;
-if (pParent->drawable.depth == pWin->drawable.depth) {
-GCPtr pGC = GetScratchGC(pWin->drawable.depth, pScreen);
-
-if (pGC) {
-ChangeGCVal val;
-
-val.val = IncludeInferiors;
-ChangeGC(NullClient, pGC, GCSubwindowMode, &val);
-ValidateGC(&pPixmap->drawable, pGC);
-(*pGC->ops->CopyArea) (&pParent->drawable,
- &pPixmap->drawable,
- pGC,
- x - pParent->drawable.x,
- y - pParent->drawable.y, w, h, 0, 0);
-FreeScratchGC(pGC);
+if (needsPixmapCopy(pWin)) {
+if (pParent->drawable.depth == pWin->drawable.depth) {
+GCPtr pGC = GetScratchGC(pWin->drawable.depth, pScreen);
+
+if (pGC) {
+ChangeGCVal val;
+
+val.val = IncludeInferiors;
+ChangeGC(NullClient, pGC, GCSubwindowMode, &val);
+ValidateGC(&pPixmap->drawable, pGC);
+(*pGC->ops->CopyArea) (&pParent->drawable,
+ &pPixmap->drawable,
+ pGC,
+ x - pParent->drawable.x,
+ y - pParent->drawable.y, w, h, 0, 0);
+FreeScratchGC(pGC);
+}
}
-}
-else {
-PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
-PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
-XID inferiors = IncludeInferiors;
-int error;
-
-PicturePtr pSrcPicture = CreatePicture(None,
- &pParent->drawable,
- pSrcFormat,
- CPSubwindowMode,
- &inferiors,
- serverClient, &error);
-
-PicturePtr pDstPicture = CreatePicture(None,
- &pPixmap->drawable,
- pDstFormat,
- 0, 0,
- serverClient, &error);
-
-if (pSrcPicture && pDstPicture) {
-CompositePicture(PictOpSrc,
- pSrcPicture,
- NULL,
- pDstPicture,
- x - pParent->drawable.x,
- y - pParent->drawable.y, 0, 0, 0, 0, w, h);
+else {
+PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
+PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
+XID inferiors = IncludeInferiors;
+int error;
+
+PicturePtr pSrcPicture = CreatePicture(None,
+ &pParent->drawable,
+ pSrcFormat,
+ CPSubwindowMode,
+ &inferiors,
+
[PATCH] xf86Mode: Don't make the mode name a "const char *"
"const" implies that the pointer is in static memory, and could easily
make people not free it after calling xf86DuplicateMode out of
confusion. Change it back to a "char *", and fix up callers to respect
that.
---
hw/xfree86/common/xf86Mode.c| 2 +-
hw/xfree86/common/xf86VidMode.c | 18 +-
hw/xfree86/common/xf86str.h | 2 +-
hw/xfree86/fbdevhw/fbdevhw.c| 2 +-
hw/xfree86/modes/xf86Modes.c| 2 +-
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/hw/xfree86/common/xf86Mode.c b/hw/xfree86/common/xf86Mode.c
index 9a5550f..495262e 100644
--- a/hw/xfree86/common/xf86Mode.c
+++ b/hw/xfree86/common/xf86Mode.c
@@ -1998,7 +1998,7 @@ xf86DeleteMode(DisplayModePtr * modeList, DisplayModePtr
mode)
mode->next->prev = mode->prev;
}
-free((void *) mode->name);
+free(mode->name);
free(mode);
}
diff --git a/hw/xfree86/common/xf86VidMode.c b/hw/xfree86/common/xf86VidMode.c
index e708b27..efd4453 100644
--- a/hw/xfree86/common/xf86VidMode.c
+++ b/hw/xfree86/common/xf86VidMode.c
@@ -421,22 +421,22 @@ VidModeSetCrtcForMode(int scrnIndex, void *mode)
}
Bool
-VidModeAddModeline(int scrnIndex, void *mode)
+VidModeAddModeline(int scrnIndex, void *mode_)
{
ScrnInfoPtr pScrn;
+DisplayModePtr mode = mode_;
if ((mode == NULL) || (!VidModeAvailable(scrnIndex)))
return FALSE;
pScrn = xf86Screens[scrnIndex];
-((DisplayModePtr) mode)->name = strdup(""); /* freed by deletemode */
-((DisplayModePtr) mode)->status = MODE_OK;
-((DisplayModePtr) mode)->next = pScrn->modes->next;
-((DisplayModePtr) mode)->prev = pScrn->modes;
-pScrn->modes->next = (DisplayModePtr) mode;
-if (((DisplayModePtr) mode)->next != NULL)
-((DisplayModePtr) mode)->next->prev = (DisplayModePtr) mode;
+mode->status = MODE_OK;
+mode->next = pScrn->modes->next;
+mode->prev = pScrn->modes;
+pScrn->modes->next = mode;
+if (mode->next != NULL)
+mode->next->prev = mode;
return TRUE;
}
@@ -533,7 +533,7 @@ VidModeCreateMode(void)
mode = malloc(sizeof(DisplayModeRec));
if (mode != NULL) {
-mode->name = "";
+mode->name = strdup(""); /* freed by deletemode */
mode->VScan = 1;/* divides refresh rate. default = 1 */
mode->Private = NULL;
mode->next = mode;
diff --git a/hw/xfree86/common/xf86str.h b/hw/xfree86/common/xf86str.h
index 643a65d..1d1c54b 100644
--- a/hw/xfree86/common/xf86str.h
+++ b/hw/xfree86/common/xf86str.h
@@ -145,7 +145,7 @@ typedef enum {
typedef struct _DisplayModeRec {
struct _DisplayModeRec *prev;
struct _DisplayModeRec *next;
-const char *name; /* identifier for the mode */
+char *name; /* identifier for the mode */
ModeStatus status;
int type;
diff --git a/hw/xfree86/fbdevhw/fbdevhw.c b/hw/xfree86/fbdevhw/fbdevhw.c
index 8cd2079..25baf2b 100644
--- a/hw/xfree86/fbdevhw/fbdevhw.c
+++ b/hw/xfree86/fbdevhw/fbdevhw.c
@@ -392,7 +392,7 @@ fbdevHWInit(ScrnInfoPtr pScrn, struct pci_device *pPci,
char *device)
/* we can use the current settings as "buildin mode" */
fbdev2xfree_timing(&fPtr->var, &fPtr->buildin);
-fPtr->buildin.name = "current";
+fPtr->buildin.name = (char *) "current";
fPtr->buildin.next = &fPtr->buildin;
fPtr->buildin.prev = &fPtr->buildin;
fPtr->buildin.type |= M_T_BUILTIN;
diff --git a/hw/xfree86/modes/xf86Modes.c b/hw/xfree86/modes/xf86Modes.c
index 43b2233..d56abda 100644
--- a/hw/xfree86/modes/xf86Modes.c
+++ b/hw/xfree86/modes/xf86Modes.c
@@ -131,7 +131,7 @@ xf86SetModeDefaultName(DisplayModePtr mode)
Bool interlaced = ! !(mode->Flags & V_INTERLACE);
char *tmp;
-free((void *) mode->name);
+free(mode->name);
XNFasprintf(&tmp, "%dx%d%s", mode->HDisplay, mode->VDisplay,
interlaced ? "i" : "");
--
2.1.0
___
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] composite: Don't bother copying the pixmap for ForgetGravity windows (v2)
If a window has ForgetGravity in its bitGravity, that very likely
means it will repaint on the ConfigureNotify / Expose event, and thus
we don't have to copy the old pixmap into the new pixmap, we can simply
leave it blank.
Preventing this copy is super simple to do and a big win on small
devices where these blits can be expensive.
A better approach would be to actually obey BitGravity correctly rather
than assume NorthWestGravity always, but this is a big speedup for the
common case.
v2: Check all subwindows to make sure they are also ForgetGravity
Cc: Adam Jackson
Signed-off-by: Jasper St. Pierre
---
composite/compalloc.c | 109 +-
1 file changed, 63 insertions(+), 46 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index 8daded0..40bf873 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -526,6 +526,21 @@ compUnredirectOneSubwindow(WindowPtr pParent, WindowPtr
pWin)
return Success;
}
+static Bool
+needsPixmapCopy(WindowPtr pWin)
+{
+WindowPtr pChild;
+
+if (pWin->bitGravity != ForgetGravity)
+return TRUE;
+
+for (pChild = pWin->firstChild; pChild; pChild = pChild->nextSib)
+if (needsPixmapCopy(pChild))
+return TRUE;
+
+return FALSE;
+}
+
static PixmapPtr
compNewPixmap(WindowPtr pWin, int x, int y, int w, int h)
{
@@ -542,54 +557,56 @@ compNewPixmap(WindowPtr pWin, int x, int y, int w, int h)
pPixmap->screen_x = x;
pPixmap->screen_y = y;
-if (pParent->drawable.depth == pWin->drawable.depth) {
-GCPtr pGC = GetScratchGC(pWin->drawable.depth, pScreen);
-
-if (pGC) {
-ChangeGCVal val;
-
-val.val = IncludeInferiors;
-ChangeGC(NullClient, pGC, GCSubwindowMode, &val);
-ValidateGC(&pPixmap->drawable, pGC);
-(*pGC->ops->CopyArea) (&pParent->drawable,
- &pPixmap->drawable,
- pGC,
- x - pParent->drawable.x,
- y - pParent->drawable.y, w, h, 0, 0);
-FreeScratchGC(pGC);
+if (needsPixmapCopy(pWin)) {
+if (pParent->drawable.depth == pWin->drawable.depth) {
+GCPtr pGC = GetScratchGC(pWin->drawable.depth, pScreen);
+
+if (pGC) {
+ChangeGCVal val;
+
+val.val = IncludeInferiors;
+ChangeGC(NullClient, pGC, GCSubwindowMode, &val);
+ValidateGC(&pPixmap->drawable, pGC);
+(*pGC->ops->CopyArea) (&pParent->drawable,
+ &pPixmap->drawable,
+ pGC,
+ x - pParent->drawable.x,
+ y - pParent->drawable.y, w, h, 0, 0);
+FreeScratchGC(pGC);
+}
}
-}
-else {
-PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
-PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
-XID inferiors = IncludeInferiors;
-int error;
-
-PicturePtr pSrcPicture = CreatePicture(None,
- &pParent->drawable,
- pSrcFormat,
- CPSubwindowMode,
- &inferiors,
- serverClient, &error);
-
-PicturePtr pDstPicture = CreatePicture(None,
- &pPixmap->drawable,
- pDstFormat,
- 0, 0,
- serverClient, &error);
-
-if (pSrcPicture && pDstPicture) {
-CompositePicture(PictOpSrc,
- pSrcPicture,
- NULL,
- pDstPicture,
- x - pParent->drawable.x,
- y - pParent->drawable.y, 0, 0, 0, 0, w, h);
+else {
+PictFormatPtr pSrcFormat = PictureWindowFormat(pParent);
+PictFormatPtr pDstFormat = PictureWindowFormat(pWin);
+XID inferiors = IncludeInferiors;
+int error;
+
+PicturePtr pSrcPicture = CreatePicture(None,
+ &pParent->drawable,
+ pSrcFormat,
+ CPSubwindowMode,
+ &inferiors,
+ serverClient, &error);
+
+PicturePtr pDstPicture = CreatePicture(None,
+ &pPixmap->drawable,
+ pDst
Re: Multiple Key Repeat
On Sat, Apr 04, 2015 at 03:17:29AM +0200, Vasil Zlatanov wrote: > Currently when you hold down two keys at the same time on the keyboard, > say for instance 'g' and '0' only the second key is repeated, producing > g000.. or 0ggg... On Microsoft Windows (given the right keyboard) if you > press 'g' and '0' at the same time it produces g0g0g0g0.. repeating both > keys at the same time. That's interesting - I never thought to do it this way. I tried it on a windows machine but couldn't reproduce the behavior; probably the keyboard saved a few bucks on the required wiring. Out of interest, can you send an evemu recording of a g0g0-like session, to see how it looks like on the evdev side? > a key. On windows one is capable of rapidly alternating two abilties > while this isn't possible for the same game running under X11. > > Can the g0g0g0g0 behaviour of repeating both keys be achieved? Not formally, the simple single-key repeat behavior is well ingrained in both the XKB protocol and server-side implementation (i.e. there's a single repeat timer and a single repeatKey per device). You might be able to achieve that client-side by setting DetectableAutoRepeat[0], ignoring the server repeats and rolling your own with a timer. I'm not sure how much of a good idea that is though. On Wayland, key repeat is left entirely to the client, with just rate/delay sent by the server, and the behavior is not specified[1]. I don't think this was intentional btw - just no one considered the multiple-key repeat option. So there you are free to do as you wish. But most toolkits implement the simple behavior AFAIK. [0] http://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#Detectable_Autorepeat [1] http://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_keyboard ___ 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] randrproto: clarify output XID lifetimes.
On 04/21/2015 05:59 PM, Dave Airlie wrote: From: Dave Airlie This just makes a note that randr won't make outputs disappear dynamically. Signed-off-by: Dave Airlie --- randrproto.txt | 8 1 file changed, 8 insertions(+) diff --git a/randrproto.txt b/randrproto.txt index 74b7c36..b2c828d 100644 --- a/randrproto.txt +++ b/randrproto.txt @@ -186,6 +186,14 @@ consider as single viewable areas. Xinerama's information now comes from the Monitors instead of directly from the CRTCs. The Monitor marked as Primary will be listed first. +1.5.2. Clarification of Output lifetimes + +With dynamic connectors being a possibility with the introduction of +MST, a lot of randr clients can't handle the XID BadMatch when a Maybe write out "DisplayPort multistream" here, for people unfamiliar with the "MST" acronym? Also, other places in this document are careful to capitalize it RandR. Otherwise, Reviewed-by: Aaron Plattner +randr output disappears. This is to clarify that going forward the +X server will not remove outputs dynamically, just mark them as +disconnected. + 1.99 Acknowledgments Our thanks to the contributors to the design found on the xpert mailing ___ 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
