Re: [PATCH] os/inputthread: Force unlock when stopping thread.

[Adam Jackson]

On Mon, 2017-11-27 at 09:59 +0100, m...@suse.com wrote:
> From: Michal Srb 
> 
> The inputthread is kept locked all the time while X server's VT is not active.
> If the X server is terminated while not active, it will be stuck forever in
> InputThreadFini waiting for the thread to join, but it wouldn't because it is
> locked.
> 
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=103782
> Signed-off-by: Michal Srb 
> ---
> This fixes the X server termination while its VT is not active. I think it
> should be safe to force unlock it from InputThreadFini - X server is
> terminating and nothing else should race there, but I am not completely sure. 

Merged, thanks:

remote: I: patch #185039 updated using rev 
71348e99a8e6a95542e483b93839168ca8f51f81.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   d5c23b2948..71348e99a8  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] composite: Propagate damagedDescendants when reparented

[Adam Jackson]

On Thu, 2017-12-14 at 12:21 -0500, Peter Harris wrote:
> If a window that is fully covered by an automatic-redirected descendant
> (even implicitly, eg. via BackingStores) is reparented, the automatic
> updates could be broken if the new parent is not marked as having
> damaged descendants.
> 
> Fix this issue by propagating the damagedDescendants flag whenever a
> window is reparented.

Nice catch. Merged, thanks:

remote: I: patch #193395 updated using rev 
d5c23b29487d5ff440abf5ed0beb22c00f21e387.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   ac138f9b31..d5c23b2948  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] modesetting: setup colormap

[Adam Jackson]

On Wed, 2017-11-15 at 19:36 +0300, Rinat Ibragimov wrote:
> Ping.

Just found this in the backlog. Merged, thanks:

remote: I: patch #184223 updated using rev 
ac138f9b31b0fba00742edbc3326afe66e28099a.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   5cb330cd5d..ac138f9b31  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 00/10] Implement RandR 1.6 (leases and non-desktop)

[Adam Jackson]

On Wed, 2018-01-24 at 10:54 +1100, Keith Packard wrote:
> Adam Jackson  writes:
> > For the actual 1.6 enablement I've been using this for a merged
> > protocol repo:
> > 
> > https://cgit.freedesktop.org/~ajax/xorgproto
> 
> That's awesome. It sounds like we should do a release of that (pre RandR
> 1.6) right away, and then a release of that with RandR 1.6 merged. Shall
> I just go do that? We're not breaking anything that distros are using as
> the old packages will hang around.

Yeah, go for it.

- 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: Video tearing with modesetting driver and Intel Sandybridge graphics

[Tino Mettler]

Hi,

for the records: after using the Intel driver for a while I removed the
xorg.conf which I created to force the usage of the Intel driver, to
see how it looks with current software.

Meanwhile, Gnome in Debian Sid just runs Xwayland and no Xorg anymore. 
And the dual head setup runs without tearing.

Regards,
Tino
___
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

[PATCH xserver] xfree86: Remove broken RANDR disabling logic (v4)

[Adam Jackson]

The only way to get at xf86Info.disableRandR from configuration is
Option "RANDR" "foo" in ServerFlags, which probably nobody is using
seeing as it's not documented. The other way it could be set is if a
screen supports RANDR 1.2, in which case we set it to avoid trying to
use the RANDR 1.1 compat code. If the second screen is not 1.2-aware
then this would mean we don't do RANDR setup on the second screen at
all, which would almost certainly crash the first time you try to do
RANDR operations on the second screen.

Fix that all by deletion, and just check whether the screen already has
RANDR initialized before installing the stub support. If you want to
disable RANDR, use the Extensions section of xorg.conf instead.

v2: Also remove a now entirely pointless log message, telling you to
ignore a line we will no longer print.

v3: Explain the fallback path in InitOutput. (Keith Packard)

v4: Check whether the RANDR private key is initialized before trying to
use it to look up the screen private.

Signed-off-by: Adam Jackson 
Reviewed-by: Keith Packard 
---
 hw/xfree86/common/xf86.h|  2 --
 hw/xfree86/common/xf86Config.c  | 12 
 hw/xfree86/common/xf86Globals.c |  2 --
 hw/xfree86/common/xf86Helper.c  |  7 ---
 hw/xfree86/common/xf86Init.c| 23 +--
 hw/xfree86/common/xf86Mode.c|  6 +-
 hw/xfree86/common/xf86Privstr.h |  2 --
 hw/xfree86/modes/xf86Crtc.c |  3 ---
 8 files changed, 18 insertions(+), 39 deletions(-)

diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
index 1c25468942..5743f0cd41 100644
--- a/hw/xfree86/common/xf86.h
+++ b/hw/xfree86/common/xf86.h
@@ -305,8 +305,6 @@ extern _X_EXPORT Bool
 xf86GetModInDevEnabled(void);
 extern _X_EXPORT Bool
 xf86GetAllowMouseOpenFail(void);
-extern _X_EXPORT void
-xf86DisableRandR(void);
 extern _X_EXPORT CARD32
 xorgGetVersion(void);
 extern _X_EXPORT CARD32
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 053cac168a..2f72c2f76c 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -634,7 +634,6 @@ typedef enum {
 FLAG_XINERAMA,
 FLAG_LOG,
 FLAG_RENDER_COLORMAP_MODE,
-FLAG_RANDR,
 FLAG_IGNORE_ABI,
 FLAG_ALLOW_EMPTY_INPUT,
 FLAG_USE_DEFAULT_FONT_PATH,
@@ -683,8 +682,6 @@ static OptionInfoRec FlagOptions[] = {
  {0}, FALSE},
 {FLAG_RENDER_COLORMAP_MODE, "RenderColormapMode", OPTV_STRING,
  {0}, FALSE},
-{FLAG_RANDR, "RandR", OPTV_BOOLEAN,
- {0}, FALSE},
 {FLAG_IGNORE_ABI, "IgnoreABI", OPTV_BOOLEAN,
  {0}, FALSE},
 {FLAG_USE_DEFAULT_FONT_PATH, "UseDefaultFontPath", OPTV_BOOLEAN,
@@ -827,15 +824,6 @@ configServerFlags(XF86ConfFlagsPtr flagsconf, 
XF86OptionPtr layoutopts)
 }
 }
 
-#ifdef RANDR
-xf86Info.disableRandR = FALSE;
-xf86Info.randRFrom = X_DEFAULT;
-if (xf86GetOptValBool(FlagOptions, FLAG_RANDR, )) {
-xf86Info.disableRandR = !value;
-xf86Info.randRFrom = X_CONFIG;
-}
-#endif
-
 #ifdef GLXEXT
 xf86Info.glxVisuals = XF86_GlxVisualsTypical;
 xf86Info.glxVisualsFrom = X_DEFAULT;
diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index 85efe3fc12..e890f05c20 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -117,8 +117,6 @@ xf86InfoRec xf86Info = {
 .miscModInDevEnabled = TRUE,
 .miscModInDevAllowNonLocal = FALSE,
 .pmFlag = TRUE,
-.disableRandR = FALSE,
-.randRFrom = X_DEFAULT,
 #if defined(CONFIG_HAL) || defined(CONFIG_UDEV) || defined(CONFIG_WSCONS)
 .forceInputDevices = FALSE,
 .autoAddDevices = TRUE,
diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
index 393a7aa881..95a90ad88d 100644
--- a/hw/xfree86/common/xf86Helper.c
+++ b/hw/xfree86/common/xf86Helper.c
@@ -1458,13 +1458,6 @@ xf86GetAllowMouseOpenFail(void)
 return xf86Info.allowMouseOpenFail;
 }
 
-void
-xf86DisableRandR(void)
-{
-xf86Info.disableRandR = TRUE;
-xf86Info.randRFrom = X_PROBED;
-}
-
 CARD32
 xf86GetModuleVersion(void *module)
 {
diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index 57b38d07e7..f9843c7192 100644
--- a/hw/xfree86/common/xf86Init.c
+++ b/hw/xfree86/common/xf86Init.c
@@ -77,6 +77,7 @@
 #include "xf86Xinput.h"
 #include "xf86InPriv.h"
 #include "picturestr.h"
+#include "randrstr.h"
 
 #include "xf86Bus.h"
 #ifdef XSERVER_LIBPCIACCESS
@@ -363,6 +364,16 @@ xf86ScreenInit(ScreenPtr pScreen, int argc, char **argv)
 return pScrn->ScreenInit (pScreen, argc, argv);
 }
 
+static void
+xf86EnsureRANDR(ScreenPtr pScreen)
+{
+#ifdef RANDR
+if (!dixPrivateKeyRegistered(rrPrivKey) ||
+!rrGetScrPriv(pScreen))
+xf86RandRInit(pScreen);
+#endif
+}
+
 /*
  * InitOutput --
  * Initialize screenInfo for all actually accessible framebuffers.
@@ -809,12 +820,12 @@ InitOutput(ScreenInfo * pScreenInfo, int argc, char 
**argv)
   

Re: [PATCH xserver] xwayland: avoid a crash with empty window pixmaps

[Daniel Stone]

Hi,

On 24 January 2018 at 16:17, Adam Jackson  wrote:
> On Wed, 2018-01-24 at 11:36 +0100, Olivier Fourdan wrote:
>> So basically, just remove the  “if
>> (RegionNotEmpty(DamageRegion(xwl_window->damage)))” would suffice?
>
> Worth a try anyway. I'm still just guessing at the root cause.

If it is the root cause, it certainly checks out:
  - window was realized, redirected, damaged
  - manual redirect removed (e.g. WM crashes or stops wanting to
present the window), pixmap destroyed (including damage)
  - possible: window is unrealized, but the DamageNotEmpty() check
doesn't pass due to the region being uninit'ed (or, if the window
lives, it's not unrealized)
  - block handler called
  - oops

Deleting the check in unrealize definitely makes sense, but perhaps to
guard against this even happening in the first place, xwl could just
place a manual redirect of its own when the window is realized and
removed when unrealized?

Cheers,
Daniel
___
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 xserver] xwayland: remove dirty window unconditionally on unrealize

[Olivier Fourdan]

This is a rare occurrence of a crash in Xwayland for which I don't have
the reproducing steps, just a core file.

The backtrace looks as follow:

  #0  raise () from /usr/lib64/libc.so.6
  #1  abort () from /usr/lib64/libc.so.6
  #2  OsAbort () at utils.c:1361
  #3  AbortServer () at log.c:877
  #4  FatalError () at log.c:1015
  #5  OsSigHandler () at osinit.c:154
  #6  
  #7  xwl_glamor_pixmap_get_wl_buffer () at xwayland-glamor.c:162
  #8  xwl_screen_post_damage () at xwayland.c:514
  #9  block_handler () at xwayland.c:665
  #10 BlockHandler () at dixutils.c:388
  #11 WaitForSomething () at WaitFor.c:219
  #12 Dispatch () at dispatch.c:422
  #13 dix_main () at main.c:287

The crash is caused by dereferencing “xwl_pixmap->buffer” in
xwl_glamor_pixmap_get_wl_buffer() because “xwl_pixmap” is NULL.

Reason for this is because the corresponding pixmap is from the root
window and xwayland is rootless by default.

This can happen if the window was mapped, redirected, damaged and
unredirected immediately, before the damage is processed by Xwayland.

Make sure to remove the dirty window from the damage list on unrealize
to prevent this from happening.

Credit goes to Adam Jackson  and Daniel Stone
 for finding the root cause the issue.

Signed-off-by: Olivier Fourdan 
---
 hw/xwayland/xwayland.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index ab7cee545..88d31f80b 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -587,8 +587,7 @@ xwl_unrealize_window(WindowPtr window)
 }
 
 wl_surface_destroy(xwl_window->surface);
-if (RegionNotEmpty(DamageRegion(xwl_window->damage)))
-xorg_list_del(_window->link_damage);
+xorg_list_del(_window->link_damage);
 DamageUnregister(xwl_window->damage);
 DamageDestroy(xwl_window->damage);
 if (xwl_window->frame_callback)
-- 
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

Re: [PATCH v3 xserver 1/2] xwayland: Add optional xdg-output support

[Adam Jackson]

On Wed, 2018-01-24 at 11:31 +0100, Olivier Fourdan wrote:

> Small bump, would need to land this patch for 1.20 so we can continue
> with fixing mutter once this is available in an Xwayland release :)

Thanks for the poke. This didn't quite build with meson, needed to
generate the new client header there too. Fixed that and some comment
typos, and merged:

remote: E: failed to find patch for rev 
da8de2a7f6ab52ef52039b0dc9978260232a34a6.
remote: I: 0 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   75408f53d4..da8de2a7f6  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] xwayland: avoid a crash with empty window pixmaps

[Olivier Fourdan]

On Wed, Jan 24, 2018 at 5:17 PM, Adam Jackson  wrote:

> On Wed, 2018-01-24 at 11:36 +0100, Olivier Fourdan wrote:
>
> > So basically, just remove the  “if
> > (RegionNotEmpty(DamageRegion(xwl_window->damage)))” would suffice?
>
> Worth a try anyway. I'm still just guessing at the root cause.
>

Right, problem is I have no idea how to reproduce the issue so I cannot
tell if that would fix it.

But I don't think removing it unconditionally would cause any trouble (and
seems like the right thing to do), so... patch to follow.

Cheers,
Olivier
___
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] xf86XvMCScreenInit: Clear pScreenPriv->dixinfo when freeing pAdapt

[Adam Jackson]

On Wed, 2018-01-24 at 12:28 +0100, Michel Dänzer wrote:
> From: Michel Dänzer 
> 
> Fixes double-free later in xf86XvMCCloseScreen, which would generally
> cause fireworks.
> 
> Signed-off-by: Michel Dänzer 

remote: I: patch #200379 updated using rev 
75408f53d4e203e462b2f13ea4b06264f0e59ad2.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   76732f498f..75408f53d4  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] xwayland: avoid a crash with empty window pixmaps

[Adam Jackson]

On Wed, 2018-01-24 at 11:36 +0100, Olivier Fourdan wrote:

> So basically, just remove the  “if
> (RegionNotEmpty(DamageRegion(xwl_window->damage)))” would suffice?

Worth a try anyway. I'm still just guessing at the root cause.

- 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: X will not start on a Thinkpad 240 using neomagic

[Michel Dänzer]

On 2018-01-24 04:55 PM, Adam Jackson wrote:
> On Wed, 2018-01-24 at 01:12 +, Alex Bowden wrote:
>>
>> I have a Thinkpad 240 with a Neomagic NM2160 and I keep having an issue
>> with the neomagic driver. I think I have narrowed it down to the kernel
>> refusing to mmap the framebuffer. I created a program called testneo.c
>> to attempt to use pci_device_map_range to access the framebuffer but
>> it always returns 22 (Invalid argument).
> 
> I'm not sure why that would fail, but...

It could be related to the Linux kernel's CONFIG_IO_STRICT_DEVMEM,
excerpt from the corresponding help text:

  If this option is switched on, the /dev/mem file only allows
  userspace access to *idle* io-memory ranges (see /proc/iomem) This
  may break traditional users of /dev/mem (dosemu, legacy X, etc...)
  if the driver using a given range cannot be disabled.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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: X will not start on a Thinkpad 240 using neomagic

[Adam Jackson]

On Wed, 2018-01-24 at 01:12 +, Alex Bowden wrote:
> Hi all,
> 
> I have a Thinkpad 240 with a Neomagic NM2160 and I keep having an issue
> with the neomagic driver. I think I have narrowed it down to the kernel
> refusing to mmap the framebuffer. I created a program called testneo.c
> to attempt to use pci_device_map_range to access the framebuffer but
> it always returns 22 (Invalid argument).

I'm not sure why that would fail, but...

> [root@tpad ~]# ./testneo
> neomagic nm2160 found
>phys_base: 0xfd00 phys_len: 0x0100
> attempt pci_device_map_range of 2MB (0x20) // from neo_driver.c

Does mapping the whole BAR work? If so it'd be trivial to change the
driver to just do that instead, and it should be harmless.

- 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

[PATCH xf86-input-evdev] Print cause of a failed open(..) call

[Christian Gmeiner]

This is quite helpful for debugging.

Signed-off-by: Christian Gmeiner 
---
 src/evdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index cffed7f..84d50c8 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -2453,7 +2453,7 @@ EvdevOpenMTDev(InputInfoPtr pInfo)
 if (pEvdev->mtdev)
 pEvdev->cur_slot = pEvdev->mtdev->caps.slot.value;
 else {
-xf86Msg(X_ERROR, "%s: Couldn't open mtdev device\n", pInfo->name);
+xf86Msg(X_ERROR, "%s: Couldn't open mtdev device (%s)\n", pInfo->name, 
strerror(errno));
 EvdevCloseDevice(pInfo);
 return FALSE;
 }
@@ -2487,7 +2487,7 @@ EvdevOpenDevice(InputInfoPtr pInfo)
 }
 
 if (pInfo->fd < 0) {
-xf86IDrvMsg(pInfo, X_ERROR, "Unable to open evdev device \"%s\".\n", 
device);
+xf86IDrvMsg(pInfo, X_ERROR, "Unable to open evdev device \"%s\" 
(%s).\n", device, strerror(errno));
 return BadValue;
 }
 
-- 
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

[PATCH xserver] xf86XvMCScreenInit: Clear pScreenPriv->dixinfo when freeing pAdapt

[Michel Dänzer]

From: Michel Dänzer 

Fixes double-free later in xf86XvMCCloseScreen, which would generally
cause fireworks.

Signed-off-by: Michel Dänzer 
---
 hw/xfree86/common/xf86xvmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/xfree86/common/xf86xvmc.c b/hw/xfree86/common/xf86xvmc.c
index a0a94c74b..c67418bf4 100644
--- a/hw/xfree86/common/xf86xvmc.c
+++ b/hw/xfree86/common/xf86xvmc.c
@@ -187,6 +187,7 @@ xf86XvMCScreenInit(ScreenPtr pScreen,
 }
 if (!pAdapt[i].xv_adaptor) {
 /* no adaptor by that name */
+pScreenPriv->dixinfo = FALSE;
 free(pAdapt);
 return FALSE;
 }
-- 
2.15.1

___
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] xwayland: avoid a crash with empty window pixmaps

[Olivier Fourdan]

Hi Adam,

On Tue, Jan 23, 2018 at 6:41 PM, Adam Jackson  wrote:

>
> Map / draw / unmap without hitting BlockHandler? I think
> xwl_unrealize_window() might be broken for that case:
>
> /* ... */
> wl_surface_destroy(xwl_window->surface);
> if (RegionNotEmpty(DamageRegion(xwl_window->damage)))
> xorg_list_del(_window->link_damage);
> DamageUnregister(xwl_window->damage);
> DamageDestroy(xwl_window->damage);
> /* ... */
>
> If (for whatever reason) the damage region wasn't empty, we'd never
>

You mean “was empty” here, right, or do I misunderstand?

(we unlink if RegionNotEmpty() so we don't unlink if the region is empty)


> unlink this window from the dirty list. Should probably just unlink it
> unconditionally. If this is indeed what's happening, then the window
> being updated in xwl_window_post_damage() would have ->mapped = 0, and
> would be not the root window itself.
>

So basically, just remove the  “if
(RegionNotEmpty(DamageRegion(xwl_window->damage)))”
would suffice?

Cheers,
Olivier
___
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 v3 xserver 1/2] xwayland: Add optional xdg-output support

[Olivier Fourdan]

Hi,

On Mon, Dec 18, 2017 at 8:52 AM, Olivier Fourdan 
wrote:

> Hi,
>
> xdg-support has now been added to mutter (in git master), can we consider
> this patch (only this one for now) which adds xdg-output support to
> Xwayland?
>
> Because of the difference between compositors, we cannot all patches at
> once, that would break either weston or mutter/gnome-shell.
>
> So we need to proceed as follow:
>
>  1. Land xdg-output support in mutter ← we're here
>  https://bugzilla.gnome.org/attachment.cgi?id=365582
>  2. Land xdg-output support in wayland
>  https://patchwork.freedesktop.org/patch/175575/
>
> Then, once we have a release of both Xwayland and mutter supporting
> xdg-output:
>
>  3. Land the patc hto send the correct output size and position in mutter
>  https://bugzilla.gnome.org/attachment.cgi?id=365575
>  4. Land the second patch of this series, to apply output scale to monitor
> resolution
>  https://patchwork.freedesktop.org/patch/175578/
>
> This way, in both weston and mutter/gnome-shell, a mode X×Y at scale 2
> will still show up as X×Y in xrandr.
>
> Cheers,
> Olivier
>


Small bump, would need to land this patch for 1.20 so we can continue with
fixing mutter once this is available in an Xwayland release :)

Cheers,
Olivier
___
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

X will not start on a Thinkpad 240 using neomagic

[Alex Bowden]

Hi all,

I have a Thinkpad 240 with a Neomagic NM2160 and I keep having an issue
with the neomagic driver. I think I have narrowed it down to the kernel
refusing to mmap the framebuffer. I created a program called testneo.c
to attempt to use pci_device_map_range to access the framebuffer but
it always returns 22 (Invalid argument).

[root@tpad ~]# ./testneo
neomagic nm2160 found
phys_base: 0xfd00 phys_len: 0x0100
attempt pci_device_map_range of 2MB (0x20) // from neo_driver.c
pci_device_map_range: Invalid argument

I went through gdb and it does not seem to be previously mapped, so I
think the error is coming from the kernel (4.14.13).

Using the vesa driver does seem to work. I also tried 'nomodeset' on the
kernel command-line.

Is there something I am missing? KMS/DRI/vgaarb?

Any suggestions are appreciated!

Thanks,
Alex

testneo.c
Description: testneo.c
___
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: XI_Enter/XI_Leave coming from a slave

[David Bokan]

On Mon, Jan 15, 2018 at 2:53 AM, Peter Hutterer 
wrote:

> On Tue, Jan 09, 2018 at 07:18:31PM -0500, David Bokan wrote:
> > Hello,
> >
> > Please bear with me as I'm utterly new to X - I'm trying to debug an
> issue
> > in Chromium when using xtest. I'm not sure if the bug is in Chromium, X,
> or
> > XTest or some combination of the three.
> >
> > There's two things that are puzzling me:
> >
> > 1) When I click mouse button 1 on a physical device, it seems that
> there's
> > some kind of grab going on: I get an XI_Enter event with NotifyGrab and
> an
> > XI_Leave with NotifyUngrab. This kind of makes sense except that I've
> > disabled the explicit device grab (XIGrabDevice) and we don't have any
> > passive grabs that I can see. So where is this grab coming from? If I
> press
> > down and move the pointer out of the window I continue to see motion
> events.
>
> it's part of the core protocol functionality, whenever a button event is
> delivered to a client it activates and implicit passive grab for that
> button. google/grep for "implicit passive grab", you should find a few
> things.
>

Thanks, that makes sense and I can reproduce the implicit grab but it still
doesn't explain the EnterNotify/XI_Enter (chromium is listening for both)
events I'm seeing after a button press. That is, the pointer is already
inside the window but on ButtonPress I get a EnterNotify+XI_Enter events. I
can't find that explained in any documentation and I can't replicate this
behavior in a stripped down repro. xtrace shows this on a button press:

000:>:0705: Event Generic(35) XInputExtension(131) ButtonPress(4)
deviceid=0x0d time=0x2c5c3858 detail=0x0001 root=0x012d
event=0x0561 child=0x056e sourceid=0x000d
000:>:0705: Event Generic(35) XInputExtension(131) ButtonPress(4)
deviceid=0x02 time=0x2c5c3858 detail=0x0001 root=0x012d
event=0x0561 child=0x056e sourceid=0x000d
000:>:0705: Event EnterNotify(7) detail=Inferior(0x02) mode=Grab(0x01)
flags=focus,same-screen time=0x2c5c3858 root=0x012d event=0x0561
child=None(0x) state=Button1
000:>:0705: Event Generic(35) XInputExtension(131) Enter(7) deviceid=0x02
time=0x2c5c3858 sourceid=0x02 mode=Grab(0x01) detail=Inferior(0x02)
root=0x012d event=0x0561 child=0x same_screen=true(0x01)
focus=true(0x01) masks=0x0002;

>
> > I tried to make a simple app to repro but couldn't. Using XIGrabButton
> > doesn't cause XI_Enter/Leave events if the click is with in the window.
> > So...where could this behavior be coming from? Figuring out how to
> > reproduce this would help me debug the issue below.
> >
> > 2) This is the real issue I'm debugging. Given the above XI_Enter/Leave
> > behavior on mouse buttons, It seems that using xtest causes us to get an
> > extra pair of XI_Enter and XI_Leave events on a mouse down with deviceid
> ==
> > 4 (xtest pointer) - in addition to the regular ones we get as described
> > above for the master pointer.
> >
> > I can kind of repro this in a test app by using XIGrabButton on
> deviceid=4.
> > This causes me to get the crossing events with deviceid=4 but I don't
> get a
> > second pair for the master pointer.
>
> I'd have to page all the details into my brain again, but IIRC grabbing a
> slave device detaches it from the master device for the duration of the
> grab. so for that time being, the event sequence is a bit different. It
> shouldn't be different for xtest devices, the grab code doesn't care about
> whether it's an xtest device or some other device.
>

This might be a red herring, Chromium always does the XIGrabDevice on the
master pointer. I've also removed the XIGrabDevice and the issue still
remains. The difference in behavior comes down to the XTest slave causing
an XI_Enter (without a matching EnterNotify) for the slave deviceid. Real
devices don't. Here's the xtrace comparing the two:

XTest:

000:>:0662: Event Generic(35) XInputExtension(131) ButtonPress(4)
deviceid=0x04 time=0x2c28195d detail=0x0001 root=0x012d
event=0x0561 child=0x056e sourceid=0x0004
___This is sent only for XTest___ 000:>:0662: Event Generic(35)
XInputExtension(131) Enter(7) deviceid=0x04 time=0x2c28195d sourceid=0x04
mode=Grab(0x01) detail=Inferior(0x02) root=0x012d event=0x0561
child=0x same_screen=true(0x01) focus=true(0x01) masks=0x0002;
000:>:0662: Event Generic(35) XInputExtension(131) ButtonPress(4)
deviceid=0x02 time=0x2c28195d detail=0x0001 root=0x012d
event=0x0561 child=0x056e sourceid=0x0004
000:>:0662: Event EnterNotify(7) detail=Inferior(0x02) mode=Grab(0x01)
flags=focus,same-screen time=0x2c28195d root=0x012d event=0x0561
child=None(0x) state=Button1
000:>:0662: Event Generic(35) XInputExtension(131) Enter(7) deviceid=0x02
time=0x2c28195d sourceid=0x02 mode=Grab(0x01) detail=Inferior(0x02)
root=0x012d event=0x0561 child=0x same_screen=true(0x01)
focus=true(0x01) masks=0x0002;