Re: [PATCH xserver] os: Call FlushClient() before sending FD-passing messages

[Giuseppe Bilotta]

On Tue, Apr 10, 2018 at 5:14 AM, Keith Packard  wrote:
>> libxcb stores received file descriptors in the buffer of size 16
>> (XCB_MAX_PASS_FD).
>> Whether it's possible that the X server will send more than 16 fds in a
>> single reply
>> and overflow the libxcb's buffer?
>
> It wouldn't be if the X server were careful in flushing things, but as
> that seems 'hard', we should probably fix xcb. I don't think that's
> terribly urgent as it would take a very strange situation to pass 16 fds
> in a short amount of time, especially in such close proximity as to end
> up not getting a reply that processes any of them in the middle of the
> sequence.

Unless this is done intentionally by a malicious server to overflow
the client's xcb buffer.


-- 
Giuseppe "Oblomov" Bilotta
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] os: Call FlushClient() before sending FD-passing messages

[Keith Packard]

Alexander Volkov  writes:

> libxcb stores received file descriptors in the buffer of size 16 
> (XCB_MAX_PASS_FD).
> Whether it's possible that the X server will send more than 16 fds in a 
> single reply
> and overflow the libxcb's buffer?

It wouldn't be if the X server were careful in flushing things, but as
that seems 'hard', we should probably fix xcb. I don't think that's
terribly urgent as it would take a very strange situation to pass 16 fds
in a short amount of time, especially in such close proximity as to end
up not getting a reply that processes any of them in the middle of the
sequence.

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[ANNOUNCE] xf86-input-libinput 0.27.1

[Peter Hutterer]

Just one bugfix, a regression introduced by the new property handling in
0.27.0 caused the property to toggle left-handed to not be initialized on
all devices that required it.

Evangelos Foutras (1):
  Fix "left handed" property not set on all pointers

Peter Hutterer (1):
  xf86-input-libinput 0.27.1

git tag: xf86-input-libinput-0.27.1

https://xorg.freedesktop.org/archive/individual/driver/xf86-input-libinput-0.27.1.tar.bz2
MD5:  bdad198a7a9f2ce2c1f90d5e6760462b  xf86-input-libinput-0.27.1.tar.bz2
SHA1: 70ba045975b6484f16d11b32fbbb7e7194d2e0fd  
xf86-input-libinput-0.27.1.tar.bz2
SHA256: d4ad8dc5ad6f962a3f15f61ba9e9f8e37fa0b57eee9f484e2bd721d60ca72ee6  
xf86-input-libinput-0.27.1.tar.bz2
SHA512: 
01379f5d71bf39214c4dff428173512df57fd12e782f3fcde757be923aa0dbf4e010a0395a81bd8e4fb518edc7e05ca1ee64b1e313eb4df5d4990315580609a1
  xf86-input-libinput-0.27.1.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-input-libinput-0.27.1.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/driver/xf86-input-libinput-0.27.1.tar.gz
MD5:  45a678eaf631ba668e10e298f24fb5ea  xf86-input-libinput-0.27.1.tar.gz
SHA1: ebbcab9222fe0d25e1a85598c069fac8954ffd12  
xf86-input-libinput-0.27.1.tar.gz
SHA256: a9c13d7769e2c8f2ec50cb6dd2d6a403807ef028e0ff4695c262bb2a18fd90b7  
xf86-input-libinput-0.27.1.tar.gz
SHA512: 
997c4068709c183bb8aa264c58ecee48c0d6f94e474cbd55204a51dc479bf23989291ac2cc2fc499827ffd66b0e8f226e727a1db55e2cb3887fd2689e3af06b2
  xf86-input-libinput-0.27.1.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-input-libinput-0.27.1.tar.gz.sig



signature.asc
Description: PGP signature
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[ANNOUNCE] xf86-input-libinput 0.27.1

[Peter Hutterer]

Just one bugfix, a regression introduced by the new property handling in
0.27.0 caused the property to toggle left-handed to not be initialized on
all devices that required it.

Evangelos Foutras (1):
  Fix "left handed" property not set on all pointers

Peter Hutterer (1):
  xf86-input-libinput 0.27.1

git tag: xf86-input-libinput-0.27.1

https://xorg.freedesktop.org/archive/individual/driver/xf86-input-libinput-0.27.1.tar.bz2
MD5:  bdad198a7a9f2ce2c1f90d5e6760462b  xf86-input-libinput-0.27.1.tar.bz2
SHA1: 70ba045975b6484f16d11b32fbbb7e7194d2e0fd  
xf86-input-libinput-0.27.1.tar.bz2
SHA256: d4ad8dc5ad6f962a3f15f61ba9e9f8e37fa0b57eee9f484e2bd721d60ca72ee6  
xf86-input-libinput-0.27.1.tar.bz2
SHA512: 
01379f5d71bf39214c4dff428173512df57fd12e782f3fcde757be923aa0dbf4e010a0395a81bd8e4fb518edc7e05ca1ee64b1e313eb4df5d4990315580609a1
  xf86-input-libinput-0.27.1.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-input-libinput-0.27.1.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/driver/xf86-input-libinput-0.27.1.tar.gz
MD5:  45a678eaf631ba668e10e298f24fb5ea  xf86-input-libinput-0.27.1.tar.gz
SHA1: ebbcab9222fe0d25e1a85598c069fac8954ffd12  
xf86-input-libinput-0.27.1.tar.gz
SHA256: a9c13d7769e2c8f2ec50cb6dd2d6a403807ef028e0ff4695c262bb2a18fd90b7  
xf86-input-libinput-0.27.1.tar.gz
SHA512: 
997c4068709c183bb8aa264c58ecee48c0d6f94e474cbd55204a51dc479bf23989291ac2cc2fc499827ffd66b0e8f226e727a1db55e2cb3887fd2689e3af06b2
  xf86-input-libinput-0.27.1.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-input-libinput-0.27.1.tar.gz.sig



signature.asc
Description: PGP signature
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce

Re: [PATCH xserver] dix: always send focus event on grab change

[Peter Hutterer]

On Mon, Apr 09, 2018 at 02:35:30PM +0200, Samuel Thibault wrote:
> Focus events are useless when 'from' and 'to' are the same.  But when
> this is the result of a (Un)GrabKeyboard request, we should always send
> them, including when the window manager had previously used XSetInputFocus
> to specify the focus on a window which happens to be now taking a grab.
> 
> This is notably needed for window manager using XI to always get keyboard
> events even during grabs, so they can determine exactly when grabbing is
> active.
> 
> Signed-off-by: Samuel Thibault 

good catch, thanks.
Reviewed-by: Peter Hutterer 

Ajax - feel free to take this one or wait for 1.20.1. It should be safe but
there could be subtle bugs. Proably not any worse than having this broken
for the last 10 years.

Cheers,
   Peter

> ---
>  dix/enterleave.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/dix/enterleave.c b/dix/enterleave.c
> index 1b341f2de..a2f625bc9 100644
> --- a/dix/enterleave.c
> +++ b/dix/enterleave.c
> @@ -1562,7 +1562,7 @@ DoFocusEvents(DeviceIntPtr pDev, WindowPtr from, 
> WindowPtr to, int mode)
>  if (!IsKeyboardDevice(pDev))
>  return;
>  
> -if (from == to)
> +if (from == to && mode != NotifyGrab && mode != NotifyUngrab)
>  return;
>  
>  CoreFocusEvents(pDev, from, to, mode);
> -- 
> 2.16.3
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] hw/xwin/glx: Allocate fbconfigs correctly

[Adam Jackson]

On Tue, 2018-04-03 at 16:54 +0100, Jon Turney wrote:
> 4b0a3cba fixed leaking of GLX fbconfigs, so now xwin needs to allocate them
> correctly (individually, rather than all at once), so they can be freed
> successfully.
> 
> Signed-off-by: Jon Turney 
> Reviewed-by: Colin Harrison 

Merged, thanks:

remote: I: patch #214546 updated using rev 
b9764b8489cabd15b50c360cfbd799fdab0883fd.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   e0a137ce5d..b9764b8489  master -> master

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] GLX: Fix a use after free error with the GLVND vendor handle.

[Adam Jackson]

On Fri, 2018-04-06 at 12:42 -0600, Kyle Brenneman wrote:
> The GLVND layer will destroy all of the vendor handles at the end of each
> server generation, but the GLX module then tries to re-use the same 
> (now-freed)
> handle in xorgGlxServerInit at the start of the next generation.
> 
> In xorgGlxCloseExtension, explicitly destroy the vendor handle and set it to
> NULL so that the next call to xorgGlxServerInit will recreate it.

Merged, thanks:

remote: Updating patchwork state for 
https://patchwork.freedesktop.org/project/Xorg/list/
remote: I: patch #215553 updated using rev 
e0a137ce5d653063604fa8d16c8498b8ac3ab3a7.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   31c1489eeb..e0a137ce5d  master -> master

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Unsupported locale errors in XOrg

[Prashanth Chandra]

Hello,

I'm getting "unsupported locale" warnings and crashes when running
programs such as xterm or dmenu on a clean install of Ubuntu 17.10

Examples:
warning: no locale support
Warning: locale not supported by Xlib, locale set to C

Here's the offending line from dmenu's source code:

if (!setlocale(LC_CTYPE, "") || !XSupportsLocale())
fputs("warning: no locale support\n", stderr);

I'm not 100% sure but I was told that this looks like an issue in XOrg.
Additionally, the problem disappears if I change my default locale to
en_US.UTF-8 instead of en_HK.UTF-8, which suggests that the issue is
specific to my locale.

Here's the output of running locale:

LANG=en_HK.UTF-8
LANGUAGE=en
LC_CTYPE="en_HK.UTF-8"
LC_NUMERIC="en_HK.UTF-8"
LC_TIME="en_HK.UTF-8"
LC_COLLATE="en_HK.UTF-8"
LC_MONETARY="en_HK.UTF-8"
LC_MESSAGES="en_HK.UTF-8"
LC_PAPER="en_HK.UTF-8"
LC_NAME="en_HK.UTF-8"
LC_ADDRESS="en_HK.UTF-8"
LC_TELEPHONE="en_HK.UTF-8"
LC_MEASUREMENT="en_HK.UTF-8"
LC_IDENTIFICATION="en_HK.UTF-8"
LC_ALL=

Here's the output of running locale -a:

C
C.UTF-8
en_HK.utf8
en_US.utf8
POSIX

Would appreciate any pointers in understanding this issue.

Prashanth
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: XRandr adaptive mirrored screens

[Adam Jackson]

On Mon, 2018-04-09 at 18:25 +0200, Prunk Dump wrote:

> Is there a way to make Xorg mirror screens by default and choose
> itself the best resolution ? Ideally a config file that I can deploy
> in all my teacher's station.

In the upcoming 1.20 release there is a feature for this, Option
"PreferCloneMode" in xorg.conf.

- ajax
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

XRandr adaptive mirrored screens

[Prunk Dump]

Hi Xorg Team !

I'm the network administrator of a French High school and I'm face of
a new problem since the integration of XRandr in Debian Stretch.

Many of my Debian Stretch stations are teacher's desktop. Each of them
are connected to a screen and to an interactive projector. I would
like that the displays are mirrored with the best common resolution.
But the problem is that :
-> Not all station are the same model. So XRandr does not give always
the same name to the outputs.
-> The screen and the projector are not always connected to the same
display ports (VGA, HDMI, ... )
-> The screen and projector sizes varies. So Xrandr don't always
select the same resolution by default.
-> Not all graphic cards support the same display resolutions.

So actually I need to make a custom Xorg config file for all my
stations individually. For each station :
-> I need to identify the output's name of the screen and of the projector
-> I need to list the supported resolutions for each output
-> I need to choose the best match resolution
-> And finally I need to I add a config file like this :

Section "Monitor"
Identifier  "HDMI-1"
Option  "Primary" "true"
Option "PreferredMode" "1280x1024"
EndSection

Section "Monitor"
Identifier  "VGA-1"
Option "Position" "0 0"
Option "PreferredMode" "1280x1024"
EndSection

Is there a way to make Xorg mirror screens by default and choose
itself the best resolution ? Ideally a config file that I can deploy
in all my teacher's station.

If someone can help me !

Thanks !

Baptiste.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [PATCH xserver] os: Call FlushClient() before sending FD-passing messages

[Alexander Volkov]

03.04.2018 21:57, Keith Packard пишет:

Alexander Volkov  writes:


Yes, it would be easier to fix this in libxcb, but I believe that it
would be more correct to do this in the X server. At least I want to
try to fix the X server.

Hrm.

The problem is that there are two streams of data here -- the stream of
fds and the stream of replies. xcb currently insists that they remain
aligned so that any fds are associated with the reply data received in
the same recvmsg operation. This allows an X server to send fds which
the client is not expecting, with the client can silently closing
them.

If we let the two streams run un-aligned, then there will be a queue of
received fds that should (unless there's a bug) eventually get
associated with the correct reply. The requirement here is looser -- we
just need to make sure the fds arrive no later than the reply data. This
seems much easier to achieve, and in fact the current X server code does
this today.

Changing xcb to allow early fds involves removing code that closes fds
received before the associated reply.

Changing the X server to ensure that fds are delivered exactly with the
associated reply data involves adding code to queue the fds and insert
additional flushes to make sure the kernel writes the fds with the start
of the reply, and then making sure that xcb doesn't discard fds received
with a partial reply.

Given these two possible solutions, I'd like to suggest that we might
prefer the simpler one.
libxcb stores received file descriptors in the buffer of size 16 
(XCB_MAX_PASS_FD).
Whether it's possible that the X server will send more than 16 fds in a 
single reply

and overflow the libxcb's buffer?
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Dual monitor problem

[Leslie Katz]

Thank you to both Michal Srb and Marius Gedminas for taking the trouble 
to reply to my query and for their suggestions. I tried Michal's 
suggestion, but the same strange behaviour occurred on the laptop's 
display when the edited script ran without the external monitor plugged 
in. Marius's suggestion to adjust the monitors configuration was 
unfortunately beyond my limited skills.


I've now run up the white flag on the startup script idea. Instead, I 
created a custom launcher with an icon that resides on my top panel. 
Now, when I boot up with the external monitor connected, I just click on 
the icon and it runs: xrandr --output eDP1 --off. At least I've reduced 
the steps needed to one simple one.


Thank you again,

Leslie



On 2018-04-09 07:00 AM, xorg-requ...@lists.x.org wrote:

Send xorg mailing list submissions to
xorg@lists.x.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.x.org/mailman/listinfo/xorg
or, via email, send a message with subject or body 'help' to
xorg-requ...@lists.x.org

You can reach the person managing the list at
xorg-ow...@lists.x.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of xorg digest..."


Today's Topics:

1. Re: Dual monitor problem (Michal Srb)
2. Re: Dual monitor problem (Michal Srb)
3. Re: Dual monitor problem (Marius Gedminas)
4. Re: Dual monitor problem (Marius Gedminas)


--

Message: 1
Date: Mon, 09 Apr 2018 09:50:53 +0200
From: Michal Srb 
To: xorg@lists.x.org
Cc: Leslie Katz , x...@freedesktop.org
Subject: Re: Dual monitor problem
Message-ID: <2873766.kkh69jj...@sheogorath.suse.cz>
Content-Type: text/plain; charset="us-ascii"

On sobota 7. dubna 2018 23:13:48 CEST Leslie Katz wrote:

I have a laptop that I usually connect to an external monitor. I use
Ubuntu 16.04 and Gnome 3.18.5. When I do connect to the external
monitor, I like to turn the laptop screen off. I can do that by going to
System Settings, Screen Display, selecting the built-in display and then
clicking "off". I'd like to automate the process. I found a script that
claimed to do that at startup. It's as follows:

#!/bin/bash

sleep 15

EXTERNAL_OUTPUT="DP1"
INTERNAL_OUTPUT="eDP1"

xrandr |grep $EXTERNAL_OUTPUT | grep " connected "
if [ $? -eq 0 ]; then
  xrandr --output $INTERNAL_OUTPUT --off --output $EXTERNAL_OUTPUT
--auto
else
  xrandr --output $INTERNAL_OUTPUT --auto --output $EXTERNAL_OUTPUT --off
fi

I made the script a startup application.

It works as advertised when the external monitor is connected. However,
when the external monitor is not connected, I first see my desktop on
the laptop screen as I would like it. Then, when the script wakes up and
runs, the bottom panel on my desktop suddenly jumps to the top of the
screen and comes to rest immediately below the top panel. I can't find
any reports of this happening to anyone else.

If anyone could explain to me why the script is causing this behavior
and tell me how to correct it, I'd be very grateful.

If there is no external output the script reconfigures the internal output and
disables the external output. I can't explain why the desktop environment
reacts to it the way it does, but maybe you could just drop the whole else
branch so nothing happens if there is no external output.

So it would look somehow like this:

...

xrandr |grep $EXTERNAL_OUTPUT | grep " connected "
if [ $? -eq 0 ]; then
  xrandr --output $INTERNAL_OUTPUT --off --output $EXTERNAL_OUTPUT --auto
fi

...

Michal Srb


--

Message: 2
Date: Mon, 09 Apr 2018 09:50:53 +0200
From: Michal Srb 
To: xorg@lists.x.org
Cc: Leslie Katz , x...@freedesktop.org
Subject: Re: Dual monitor problem
Message-ID: <2873766.kkh69jj...@sheogorath.suse.cz>
Content-Type: text/plain; charset="us-ascii"

On sobota 7. dubna 2018 23:13:48 CEST Leslie Katz wrote:

I have a laptop that I usually connect to an external monitor. I use
Ubuntu 16.04 and Gnome 3.18.5. When I do connect to the external
monitor, I like to turn the laptop screen off. I can do that by going to
System Settings, Screen Display, selecting the built-in display and then
clicking "off". I'd like to automate the process. I found a script that
claimed to do that at startup. It's as follows:

#!/bin/bash

sleep 15

EXTERNAL_OUTPUT="DP1"
INTERNAL_OUTPUT="eDP1"

xrandr |grep $EXTERNAL_OUTPUT | grep " connected "
if [ $? -eq 0 ]; then
  xrandr --output $INTERNAL_OUTPUT --off --output $EXTERNAL_OUTPUT
--auto
else
  xrandr --output $INTERNAL_OUTPUT --auto --output $EXTERNAL_OUTPUT --off
fi

I made the script a startup application.

It works as advertised when the external monitor is connected. However,
when the external monitor is not connected, I first see my desktop on
the laptop screen as I would like it. Then, when the script 

[PATCH xserver] dix: always send focus event on grab change

[Samuel Thibault]

Focus events are useless when 'from' and 'to' are the same.  But when
this is the result of a (Un)GrabKeyboard request, we should always send
them, including when the window manager had previously used XSetInputFocus
to specify the focus on a window which happens to be now taking a grab.

This is notably needed for window manager using XI to always get keyboard
events even during grabs, so they can determine exactly when grabbing is
active.

Signed-off-by: Samuel Thibault 
---
 dix/enterleave.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dix/enterleave.c b/dix/enterleave.c
index 1b341f2de..a2f625bc9 100644
--- a/dix/enterleave.c
+++ b/dix/enterleave.c
@@ -1562,7 +1562,7 @@ DoFocusEvents(DeviceIntPtr pDev, WindowPtr from, 
WindowPtr to, int mode)
 if (!IsKeyboardDevice(pDev))
 return;
 
-if (from == to)
+if (from == to && mode != NotifyGrab && mode != NotifyUngrab)
 return;
 
 CoreFocusEvents(pDev, from, to, mode);
-- 
2.16.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: NotifyGrab

[Samuel Thibault]

Hello,

I have kept the story below for the record and attached the testcase
again in case it could be useful.

So the issue is that DoFocusEvents does not send focus events if
from == to, which happens here because the focus-grab.c is calling
XSetInputFocus to set the input focus (as expected for a window manager)
and it happens that it's that window which is requesting a grab, so from
== to. But since it is a grab, we should really emit the focus event, so
that listeners (notably XI listeners) are aware of the grabbing taking
place.  I have posted a patch fixing it titled "dix: always send focus
event on grab change" on xorg-devel@lists.x.org for review.

Cheers,
Samuel

Samuel Thibault, le ven. 22 déc. 2017 01:01:04 +0100, a ecrit:
> Samuel Thibault, on jeu. 21 déc. 2017 18:21:39 +0100, wrote:
> > Samuel Thibault, on jeu. 21 déc. 2017 17:50:54 +0100, wrote:
> > > One additionnal piece of information: it seems that what makes compiz
> > > have the issue (compared to my simple X root event listener) is the call
> > > to
> > > 
> > > XSetInputFocus (s->dpy (), priv->id, RevertToPointerRoot, CurrentTime);
> > > 
> > > on the window that after that acquires the grab.
> > 
> > Here are reproducers.
> > 
> > - First run focus-grab on a bare X server
> > - then run grab, which opens a window on the top left corner.
> > - Move the mouse to it.
> >   -> in focus-grab the enter notify handler calls XSetInputFocus [*]
> > - press the g key  
> > 
> > The result is this: On the ./grab side:
> > 
> > focus out 4194305 0
> > focus in 4194305 0
> > 0: ||
> > 1: |g|
> > 0:1|g|
> > res 0
> > 
> > I.e. it got the 'g' keypress event, and successfully called XGrabKeyboard.
> > And on the ./focus-grab side:
> > 
> > started
> > create 4194305
> > enter 4194305 0
> > 1
> > core focus out 4194305 0
> > core focus out 38 0
> > core focus out 38 0
> > core focus in 38 0
> > core focus in 4194305 0
> > focus out 6 0
> > key press 7 7 42 0
> > key release 7 7 42 0
> > 
> > I.e. it saw the creation of the window, catched entering the window
> > and set XSetInputFocus, which generate focus events, then saw the 'g'
> > keypress (77 is my numlock) but didn't see any grab-related focus
> > events. That's my concern.
> 
> And without the XSetInputFocus call, one gets
> 
> 1: |g|
> 0:1|g|
> res 0
> focus out 4194305 1
> focus in 4194305 1
> 
> and
> 
> started
> create 4194305
> enter 4194305 0
> key press 7 7 42 0
> core focus out 4194305 1
> core focus out 38 1
> core focus out 38 1
> core focus in 38 1
> core focus in 4194305 1
> focus out 6 1
> key release 7 7 42 0
> 
> i.e. there really is the grab information.
> 
> BTW, this is X server core 1.19.5 (Debian Buster up to date)
> 
> Samuel

-- 
Samuel
>   dvips -o $@ $< 
Faut faire gffe de pas te couper avec ton truc, t'as mis des ciseaux ($<)
partout :))
-+- Dom in Guide du linuxien pervers - "J'aime pas les Makefile !" -+-
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main (int argc, char **argv) {
	Display *mydisplay, *mydisplay2;
	Window mywindow;

	XEvent myevent;
	KeySym mykey;

	XSizeHints myhint;
	XComposeStatus status;
	memset(,0,sizeof(status));

	int myscreen;
	unsigned long myforeground, mybackground, valuemask;
	XSetWindowAttributes xswa;
	int i;
	char text[10];
	int done;

	mydisplay=XOpenDisplay("");
	myscreen=DefaultScreen(mydisplay);
	mybackground=WhitePixel(mydisplay, myscreen);
	myforeground=BlackPixel(mydisplay, myscreen);

	myhint.x=0; myhint.y=0;
	myhint.width=400; myhint.height=400;
	myhint.flags=PPosition|PSize;

	mywindow=XCreateSimpleWindow(mydisplay, DefaultRootWindow (mydisplay), myhint.x, myhint.y, myhint.width, myhint.height, 5 /*border*/, myforeground, mybackground);

	XSetWindowBackgroundPixmap(mydisplay, mywindow, None);
	XMapRaised(mydisplay, mywindow);

	XSelectInput(mydisplay, mywindow, FocusChangeMask | KeyPressMask);

	while(1) {
		XNextEvent (mydisplay, );
		switch(myevent.type) {
			case MappingNotify:
XRefreshKeyboardMapping();
break;
			case ButtonPress:
fprintf(stderr,"button press\n");
break;
			case KeyPress:
i = XLookupString(, text, 10, , );
fprintf(stderr,"%d: |%s|\n",i,text);
if (i == 1 /*len*/ && text[0] == 'q') done = 1;
char buf[128];
int foo;
if (XkbTranslateKeySym(mydisplay, , 0, buf, sizeof(buf), ))
	fprintf(stderr,"%d:%d|%s|\n", foo, strlen(buf), buf);
if (myevent.xkey.keycode == 42)
{
	int res;
	res = XGrabKeyboard (mydisplay, mywindow, True, GrabModeAsync, GrabModeAsync, CurrentTime);
	fprintf(stderr,"res %d\n", res);
}
else if (myevent.xkey.keycode == 43)
{
	int res;
	res = XUngrabKeyboard(mydisplay, CurrentTime);
	fprintf(stderr,"res %d\n", res);
} else if (myevent.xkey.keycode == 38)
	exit(1);
break;
			case KeyRelease:
break;
			case FocusIn:
fprintf(stderr, "focus in %d %d\n", myevent.xfocus.window, myevent.xfocus.mode);
break;
			case FocusOut:
fprintf(stderr, "focus out 

Re: Dual monitor problem

[Marius Gedminas]

On Sat, Apr 07, 2018 at 04:13:48PM -0500, Leslie Katz wrote:
> I have a laptop that I usually connect to an external monitor. I use Ubuntu
> 16.04 and Gnome 3.18.5. When I do connect to the external monitor, I like to
> turn the laptop screen off. I can do that by going to System Settings,
> Screen Display, selecting the built-in display and then clicking "off". I'd
> like to automate the process.

GNOME should already automate that.  It remembers your settings for each
set of connected monitor configurations, and when you plug in or unplug
a monitor, it restores them.

The configurations themselves are stored in ~/.config/monitors.xml.  The
process responsible for applying them on hotplug/unplug events is
gnome-settings-daemon.  (Ubuntu might have a unity-settings-daemon which
is a fork of an older version of gnome-settings-daemon, but it does the
same thing.)

There's a way to turn that autoconfiguration off, which might explain
why it's not happening for you.  It's a setting somewhere in
dconf/gsettings, but I don't remember exactly where.

HTH,
Marius Gedminas
-- 
Computers are not intelligent.  They only think they are.


signature.asc
Description: PGP signature
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [PATCH app/xdpyinfo v2] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

[Giuseppe Bilotta]

On Sun, Apr 8, 2018 at 8:25 PM, Pali Rohár  wrote:
> On Sunday 08 April 2018 19:22:28 Giuseppe Bilotta wrote:
>> The values reported by xdpyinfo aren't bogus, they are what the core
>> protocol is providing.
>
> For users as human readable output from xdpyinfo, those values are
> bogus. For users it does not matter how xdpyinfo obtain those values.
> Just that it provides values which do not match reality.
>
> I understand that those values comes from X server and xdpyinfo just
> print what it receive. But for end-users of xdpyinfo this is really
> irrelevant. That tool worked correctly prior changes in X server (do not
> remember version).

If your issue is with the default DPI reported by the X server, that's
the thing you should be fixing,
not what xdpyinfo is reporting.

>> > There are plenty of bugs and lot of reports about this problem.
>>
>> Because people are using the wrong tool.
>
> I agree, but you can look at it from other side. This tool worked with
> older X servers. If it is stopped working with new X servers, then
> either tool itself should write information about it or do not report
> those values at all.
>
> Providing wrong information without any warning either in --help,
> manpage or in stdout is really the worst solution.

There is no other side. The tool still work as intended regardless of
the X server release, the information it provides is still exactly the
same, and as correct as it used to be —in the sense that it matches
exactly what the server claims. Users using it for a different purpose
fall in the category of this relevant XKCD https://xkcd.com/1172/

Again, your issue isn't what xdpyinfo reports, but what the _server_
reports, and you're trying to fix it in the wrong place.

>> > Really what is the purpose of reporting bogus values?
>>
>> As mentioned, the purpose of xdpyinfo is to report what the core
>> protocol reports (modulo use of the -ext flag and related ones).
>
> The main problem is that this is not documented, nor written anywhere.

If you feel that the man page and usage help text should better
clarify that all shown values are what the X core protocol reports,
modulo -ext option usage, that can be fixed.

> And output of xdpyinfo does not looks like core information for
> end-users.
>
> What end user reads? He sees resolution (which for with the most common
> variant for one monitor) matches what he has configured and the he sees
> DPI which does not match his monitor. So it is fully bogus for him.

And as above, xdpyinfo is not where this should be fixed.

>> So it is important that xdpyinfo keeps reporting what is reporting
>> because (1) it's its purpose and (2) it's the only way to get what
>> legacy (non-RANDR-aware) clients get.
>
> Ok, it makes sense to retrieve this information, but for sure it should
> not be used by new applications, scripts and also users to retrieve DPI.
>
> But main problem is that xdpyinfo does not look like for end-users that
> it reports "legacy" values which end-users should not read for xrandr
> 1.2+ display.

And that's why the solution to this is to put support for the RANDR
extension in xdpyinfo the correct way (i.e. accessible with -ext
RANDR), and teach users and scripts to rely on that information as
appropriate.

>> Now one could argue that in the case of single output X11 could
>> automatically set the DPI to the one of the only connected output
>> (something I actually agree with), but that's (a) a separate issue and
>> (b) not without its downsides (e.g. should it automatically change
>> whenever the output changes? what should be done when a new output
>> gets connected? what should be done when an output gets disconnected
>> and we're left with one output again? etc).
>
> Those are separate issues, which are really out-of-scope of this
> discussion. Personally I like idea that DisplayWidthMM() and
> DisplayHeightMM() are calculated to 96 DPI as 96 DPI is sane default for
> legacy applications. And special case for one monitor setup is bad
> because it would change behavior of applications when more then one
> monitor is connected.

But that's the core of the issue: xdpyinfo reporting the core value
when there are two monitors and the monitor value when there is a
single one would be no less inconsistent.

The only consistent solution  is for xdpyinfo to keep working as
designed, provide the RANDR data via -ext RANDR, consistently with the
rest, and teach users and script to use that information when
possible.

Changes to what the core protocol should report by default remain a
separate matter, which may be worth discussing, but which remains
independent from the scope of this patch.


-- 
Giuseppe "Oblomov" Bilotta
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

[Mike Lothian]

Switching between egl and glx can only be done these days by editing the
kwinrc file (egl however is used by default on wayland I believe), egl was
still enabled from years ago when switching was easy

I've attached some coredumps on the bug, though I don't have any debugging
compiled into the binaries so I'm not sure how useful they are

On Mon, 9 Apr 2018 at 10:45 Roman Gilg  wrote:

> On Sat, Apr 7, 2018 at 9:56 AM, Mike Lothian  wrote:
> > Switching to glx from egl gets things started for me
>
> Do you mean switching from egl to glx as in switching the compositing
> backend? And it did not work with egl backend but with glx?
>
> The egl backend on X in KWin isn't supported well at the moment and
> switching between them shouldn't be possible anymore from the control
> module in system settings.
>
> Can you post a backtrace from the dying process? Is it KWin or
> Plasmashell? The one of Plasmashell in the Gentoo bug report is with
> an AMD card.
>
> Cheers
> Roman
>
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

[Roman Gilg]

On Sat, Apr 7, 2018 at 9:56 AM, Mike Lothian  wrote:
> Switching to glx from egl gets things started for me

Do you mean switching from egl to glx as in switching the compositing
backend? And it did not work with egl backend but with glx?

The egl backend on X in KWin isn't supported well at the moment and
switching between them shouldn't be possible anymore from the control
module in system settings.

Can you post a backtrace from the dying process? Is it KWin or
Plasmashell? The one of Plasmashell in the Gentoo bug report is with
an AMD card.

Cheers
Roman
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] revolve possible null pointer dereference issue found by cppcheck

[Илья Шипицин]

thank you.
sorry for false positive

2018-04-09 12:43 GMT+05:00 Michal Srb :

> On pondělí 9. dubna 2018 9:31:54 CEST Ilya Shipitsin wrote:
> > [dix/inpututils.c:909] -> [dix/inpututils.c:905]: (warning) Either the
> > condition 'if(list)' is redundant or there is possible null pointer
> > dereference: list.
>
> I think this is a false positive by cppcheck. It looks like it
> misinterprets
> the `list.next` in the macro as dereferencing the `list` variable.
>
> The `nt_list_init(opt, list.next)` macro expands to:
>
>   (opt)->list.next = NULL
>
> So wrapping it in the `if (list)` condition is not correct.
>
> Michal Srb
>
> > ---
> >  dix/inpututils.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/dix/inpututils.c b/dix/inpututils.c
> > index 6bff9efab..f4c386a24 100644
> > --- a/dix/inpututils.c
> > +++ b/dix/inpututils.c
> > @@ -902,7 +902,9 @@ input_option_new(InputOption *list, const char *key,
> > const char *value) if (!opt)
> >  return NULL;
> >
> > -nt_list_init(opt, list.next);
> > +if (list)
> > +nt_list_init(opt, list.next);
> > +
> >  input_option_set_key(opt, key);
> >  input_option_set_value(opt, value);
>
>
>
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Dual monitor problem

[Michal Srb]

On sobota 7. dubna 2018 23:13:48 CEST Leslie Katz wrote:
> I have a laptop that I usually connect to an external monitor. I use
> Ubuntu 16.04 and Gnome 3.18.5. When I do connect to the external
> monitor, I like to turn the laptop screen off. I can do that by going to
> System Settings, Screen Display, selecting the built-in display and then
> clicking "off". I'd like to automate the process. I found a script that
> claimed to do that at startup. It's as follows:
> 
> #!/bin/bash
> 
> sleep 15
> 
> EXTERNAL_OUTPUT="DP1"
> INTERNAL_OUTPUT="eDP1"
> 
> xrandr |grep $EXTERNAL_OUTPUT | grep " connected "
> if [ $? -eq 0 ]; then
>  xrandr --output $INTERNAL_OUTPUT --off --output $EXTERNAL_OUTPUT
> --auto
> else
>  xrandr --output $INTERNAL_OUTPUT --auto --output $EXTERNAL_OUTPUT --off
> fi
> 
> I made the script a startup application.
> 
> It works as advertised when the external monitor is connected. However,
> when the external monitor is not connected, I first see my desktop on
> the laptop screen as I would like it. Then, when the script wakes up and
> runs, the bottom panel on my desktop suddenly jumps to the top of the
> screen and comes to rest immediately below the top panel. I can't find
> any reports of this happening to anyone else.
> 
> If anyone could explain to me why the script is causing this behavior
> and tell me how to correct it, I'd be very grateful.

If there is no external output the script reconfigures the internal output and 
disables the external output. I can't explain why the desktop environment 
reacts to it the way it does, but maybe you could just drop the whole else 
branch so nothing happens if there is no external output.

So it would look somehow like this:

...

xrandr |grep $EXTERNAL_OUTPUT | grep " connected "
if [ $? -eq 0 ]; then
 xrandr --output $INTERNAL_OUTPUT --off --output $EXTERNAL_OUTPUT --auto
fi

...

Michal Srb
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [PATCH] revolve possible null pointer dereference issue found by cppcheck

[Michal Srb]

On pondělí 9. dubna 2018 9:31:54 CEST Ilya Shipitsin wrote:
> [dix/inpututils.c:909] -> [dix/inpututils.c:905]: (warning) Either the
> condition 'if(list)' is redundant or there is possible null pointer
> dereference: list.

I think this is a false positive by cppcheck. It looks like it misinterprets 
the `list.next` in the macro as dereferencing the `list` variable.

The `nt_list_init(opt, list.next)` macro expands to:

  (opt)->list.next = NULL

So wrapping it in the `if (list)` condition is not correct.

Michal Srb

> ---
>  dix/inpututils.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/dix/inpututils.c b/dix/inpututils.c
> index 6bff9efab..f4c386a24 100644
> --- a/dix/inpututils.c
> +++ b/dix/inpututils.c
> @@ -902,7 +902,9 @@ input_option_new(InputOption *list, const char *key,
> const char *value) if (!opt)
>  return NULL;
> 
> -nt_list_init(opt, list.next);
> +if (list)
> +nt_list_init(opt, list.next);
> +
>  input_option_set_key(opt, key);
>  input_option_set_value(opt, value);


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] revolve possible null pointer dereference issue found by cppcheck

[Ilya Shipitsin]

[dix/inpututils.c:909] -> [dix/inpututils.c:905]: (warning) Either the condition
'if(list)' is redundant or there is possible null pointer dereference: list.

Signed-off-by: Ilya Shipitsin 
---
 dix/inpututils.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/dix/inpututils.c b/dix/inpututils.c
index 6bff9efab..f4c386a24 100644
--- a/dix/inpututils.c
+++ b/dix/inpututils.c
@@ -902,7 +902,9 @@ input_option_new(InputOption *list, const char *key, const 
char *value)
 if (!opt)
 return NULL;
 
-nt_list_init(opt, list.next);
+if (list)
+nt_list_init(opt, list.next);
+
 input_option_set_key(opt, key);
 input_option_set_value(opt, value);
 
-- 
2.14.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel