Re: [PATCH] xkb: fix turbo-repeat of RedirectKey-ed keysyms

[Daniel Stone]

Hi,

On 14 September 2016 at 11:47, Daniel Stone  wrote:
> RedirectKey() action had been broken by commit 2e6190.
> A dropped check caused over-intense autorepeat of keysyms enriched
> with the action.
>
> Previous to this commit, the check wrapped the entire switch() block,
> which was dropped with the move to a separate function.
>
> Restore the checking.

Please also consider this for a stable release, since by my reading
this breaks actual AccessX functionality.

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

Re: [PATCH xserver] modesetting: allow switching from software to hardware cursors.

[Michael Thayer]

On 14.09.2016 12:07, Hans de Goede wrote:

Hi,

On 13-09-16 17:42, Michael Thayer wrote:

Currently if modesetting ever fails to set a hardware cursor it will
switch
to using a software cursor and never go back.  Change this to try a
hardware
cursor first every time a new one is set.  This is needed because
hardware
may be able to handle some cursors in harware and others not, or virtual
hardware may be able to handle hardware cursors at some times and not
others.

Signed-off-by: Michael Thayer 
---
Checked the current git source and this change is still needed.  This
is an
updated patch which takes into account changes in the driver source since
the original patch was created.  Note that other than building I have not
had a chance to test that the updated patch still works, but the
difference
against the original is pretty minimal.

 hw/xfree86/drivers/modesetting/drmmode_display.c | 36
+---
 hw/xfree86/drivers/modesetting/drmmode_display.h |  1 -
 2 files changed, 13 insertions(+), 24 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 6b933e4..ad39f76 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -756,33 +756,23 @@ drmmode_set_cursor(xf86CrtcPtr crtc)
 drmmode_ptr drmmode = drmmode_crtc->drmmode;
 uint32_t handle = drmmode_crtc->cursor_bo->handle;
 modesettingPtr ms = modesettingPTR(crtc->scrn);
+CursorPtr cursor = xf86CurrentCursor(crtc->scrn->pScreen);
 int ret;

-if (!drmmode_crtc->set_cursor2_failed) {
-CursorPtr cursor = xf86CurrentCursor(crtc->scrn->pScreen);
-
-ret =
-drmModeSetCursor2(drmmode->fd,
drmmode_crtc->mode_crtc->crtc_id,
-  handle, ms->cursor_width,
ms->cursor_height,
-  cursor->bits->xhot, cursor->bits->yhot);
-if (!ret)
-return TRUE;
-
-drmmode_crtc->set_cursor2_failed = TRUE;
-}
-
-ret = drmModeSetCursor(drmmode->fd,
drmmode_crtc->mode_crtc->crtc_id, handle,
-   ms->cursor_width, ms->cursor_height);
+ret =
+drmModeSetCursor2(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
+  handle, ms->cursor_width, ms->cursor_height,
+  cursor->bits->xhot, cursor->bits->yhot);
+if (!ret)
+return TRUE;

-if (ret) {
-xf86CrtcConfigPtr xf86_config =
XF86_CRTC_CONFIG_PTR(crtc->scrn);
-xf86CursorInfoPtr cursor_info = xf86_config->cursor_info;
+/* -EINVAL can mean bad cursor parameters or Cursor2 API not
supported. */
+if (ret == -EINVAL)


You're reintroducing the -EINVAL check which was deliberately dropped
recently because sometimes another error is given while the non 2 version
might still work, please drop this bit.


I see that the commit message to 074cf587 states that sometimes ENXIO 
can be returned.  Sorry if I am being blind here (it would not be the 
first time), but I cannot see which path that could happen in.  It also 
seems a bit silly to unconditionally call drmModeSetCursor() every time 
drmModeSetCursor2() fails if it can be reasonably avoided.  So if I am 
being blind, would it be alright if I made the test (ret == -EINVAL || 
ret == ENXIO)?  Not that it would bring the world to an end, but still.


Regards,

Michael


Also please actually test the patch before posting a new version.

Other then that this looks like an ok change to me.

Regards,

Hans




+ret = drmModeSetCursor(drmmode->fd,
drmmode_crtc->mode_crtc->crtc_id, handle,
+   ms->cursor_width, ms->cursor_height);

-cursor_info->MaxWidth = cursor_info->MaxHeight = 0;
-drmmode_crtc->drmmode->sw_cursor = TRUE;
-/* fallback to swcursor */
-return FALSE;
-}
+if (ret)
+return FALSE; /* fallback to swcursor */
 return TRUE;
 }

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h
b/hw/xfree86/drivers/modesetting/drmmode_display.h
index 50976b8..5170bf5 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.h
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
@@ -92,7 +92,6 @@ typedef struct {
 int dpms_mode;
 struct dumb_bo *cursor_bo;
 Bool cursor_up;
-Bool set_cursor2_failed;
 Bool first_cursor_load_done;
 uint16_t lut_r[256], lut_g[256], lut_b[256];




--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister 
der Handelskammer Midden-Nederland, Nr. 30143697

Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

[PATCH] xkb: fix turbo-repeat of RedirectKey-ed keysyms

[Daniel Stone]

From: Mihail Konev 

RedirectKey() action had been broken by commit 2e6190.
A dropped check caused over-intense autorepeat of keysyms enriched
with the action.

Previous to this commit, the check wrapped the entire switch() block,
which was dropped with the move to a separate function.

Restore the checking.

Signed-off-by: Mihail Konev 
Reviewed-by: Daniel Stone 
---
 xkb/xkbActions.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xkb/xkbActions.c b/xkb/xkbActions.c
index 048ed44..2ffd3fa 100644
--- a/xkb/xkbActions.c
+++ b/xkb/xkbActions.c
@@ -1337,7 +1337,8 @@ XkbHandleActions(DeviceIntPtr dev, DeviceIntPtr kbd, 
DeviceEvent *event)
 }
 
 sendEvent = _XkbApplyFilters(xkbi, key, );
-XkbActionGetFilter(dev, event, key, , );
+if (sendEvent)
+XkbActionGetFilter(dev, event, key, , );
 }
 else {
 if (!keyEvent)
-- 
2.9.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

Fwd: [PATCH v2 xserver] xkb: fix turbo-repeat of RedirectKey-ed keysyms

[Daniel Stone]

Hi,
Here's the notes from Mihail, which I'd accidentally dropped whilst
passing this on.

Cheers,
Daniel


-- Forwarded message --
From: Mihail Konev 
Date: 14 September 2016 at 07:45
Subject: [PATCH v2 xserver] xkb: fix turbo-repeat of RedirectKey-ed keysyms
To: Daniel Stone 


RedirectKey() action had been broken by commit 2e6190.
A dropped check caused over-intense autorepeat of keysyms enriched
with the action.

Restore the checking.

Signed-off-by: Mihail Konev 
---

Apologies for misconstructed v1 message.
Here is the one with diff and text in proper order.

RedirectKey does not occur in /usr/share/X11/xkb,
so no wonder this went unnoticed.

To reproduce:

  File 'compat/turbo':
  ```
  default partial xkb_compatibility "turbo" {
  interpret ISO_Emphasize+AnyOfOrNone(all) {
  repeat = True;
  action = RedirectKey(KeyCode=);
  };
  };
  ```

  File 'symbols/turbo':
  ```
  default partial alphanumeric_keys modifier_keys
  xkb_symbols "turbo" {
  key  { [ ISO_Emphasize ] };
  };
  ```

  File 'turbo.xkb':
  ```
  xkb_keymap {
  xkb_keycodes { include "evdev" };
  xkb_types{ include "complete" };
  xkb_compat   { include "complete+turbo" };
  xkb_symbols  { include "pc+inet(evdev)+us+turbo" };
  xkb_geometry { include "pc(pc104)" };
  };
  ```

  File 'turbo.sh':
  ```
  #!/bin/sh
  xkbcomp -I. turbo.xkb $DISPLAY
  ```

  Run 'sh turbo.sh'.
  The Insert key would become a turbo-repeating Left.
  Xserver 1.17.* and before do not exhibit that behaviour.

 xkb/xkbActions.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xkb/xkbActions.c b/xkb/xkbActions.c
index 048ed441ab1b..2ffd3fadccf6 100644
--- a/xkb/xkbActions.c
+++ b/xkb/xkbActions.c
@@ -1337,7 +1337,8 @@ XkbHandleActions(DeviceIntPtr dev, DeviceIntPtr
kbd, DeviceEvent *event)
 }

 sendEvent = _XkbApplyFilters(xkbi, key, );
-XkbActionGetFilter(dev, event, key, , );
+if (sendEvent)
+XkbActionGetFilter(dev, event, key, , );
 }
 else {
 if (!keyEvent)
--
2.9.2
___
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 v3] xwayland: handle EAGAIN on Wayland fd

[Olivier Fourdan]

wl_display_flush() can fail with EAGAIN and Xwayland would make this a
fatal error.

When this happens, it means that Xwayland has flooded the Wayland file
descriptor, either because the Wayland compositor cannot cope or more
likely because of a deadlock situation where the Wayland compositor is
blocking, waiting for an X reply while Xwayland tries to write data to
the Wayland file descriptor.

The general consensus to avoid the deadlock is for the Wayland
compositor to never issue blocking X11 roundtrips, but in practice
blocking rountrips can occur in various places, including Xlib calls
themselves so this is not always achievable without major surgery in the
Wayland compositor/Window manager.

What this patch does is to avoid dispatching to the Wayland file
descriptor until it becomes available for writing again, while at the
same time continue processing X11 requests to release the deadlock.

This is not perfect, as there is still the possibility of another X
client hammering the connection and we'll still fail writing to the
Wayland connection eventually, but this improves things enough to avoid
a 100% repeatable crash with vlc and gtkperf.

Also, it is worth considering that window managers and Wayland
compositors such as mutter already have a higher priority than other
regular X clients thanks to XSyncSetPriority(), mitigating the risk.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1278159
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=763400
Signed-off-by: Olivier Fourdan 
---
 v2: oops, need to poll() on EAGAIN between retries
 v3: Mostly a rewrite, non-blocking on poll()

 hw/xwayland/xwayland.c | 34 +++---
 hw/xwayland/xwayland.h |  1 +
 2 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 847321e..2efbff8 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef XF86VIDMODE
 #include 
@@ -470,6 +471,9 @@ xwl_read_events (struct xwl_screen *xwl_screen)
 {
 int ret;
 
+if (xwl_screen->wait_flush)
+return;
+
 ret = wl_display_read_events(xwl_screen->display);
 if (ret == -1)
 FatalError("failed to read Wayland events: %s\n", strerror(errno));
@@ -481,10 +485,25 @@ xwl_read_events (struct xwl_screen *xwl_screen)
 FatalError("failed to dispatch Wayland events: %s\n", strerror(errno));
 }
 
+static int
+xwl_display_pollout (struct xwl_screen *xwl_screen, int timeout)
+{
+struct pollfd poll_fd;
+
+poll_fd.fd = wl_display_get_fd(xwl_screen->display);
+poll_fd.events = POLLOUT;
+
+return xserver_poll(_fd, 1, timeout);
+}
+
 static void
 xwl_dispatch_events (struct xwl_screen *xwl_screen)
 {
-int ret;
+int ret = 0;
+int ready;
+
+if (xwl_screen->wait_flush)
+goto pollout;
 
 while (xwl_screen->prepare_read == 0 &&
wl_display_prepare_read(xwl_screen->display) == -1) {
@@ -496,9 +515,18 @@ xwl_dispatch_events (struct xwl_screen *xwl_screen)
 
 xwl_screen->prepare_read = 1;
 
-ret = wl_display_flush(xwl_screen->display);
-if (ret == -1)
+pollout:
+ready = xwl_display_pollout(xwl_screen, 5);
+if (ready == -1)
+FatalError("error polling on XWayland fd: %s\n", strerror(errno));
+
+if (ready > 0)
+ret = wl_display_flush(xwl_screen->display);
+
+if (ret == -1 && errno != EAGAIN)
 FatalError("failed to write to XWayland fd: %s\n", strerror(errno));
+
+xwl_screen->wait_flush = (ready == 0 || ret == -1);
 }
 
 static void
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index db3dd0b..3ce7a63 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -83,6 +83,7 @@ struct xwl_screen {
 #define XWL_FORMAT_RGB565   (1 << 2)
 
 int prepare_read;
+int wait_flush;
 
 char *device_name;
 int drm_fd;
-- 
2.9.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 xserver] modesetting: allow switching from software to hardware cursors.

[Hans de Goede]

Hi,

On 14-09-16 15:53, Michael Thayer wrote:

On 14.09.2016 12:07, Hans de Goede wrote:

Hi,

On 13-09-16 17:42, Michael Thayer wrote:

Currently if modesetting ever fails to set a hardware cursor it will
switch
to using a software cursor and never go back.  Change this to try a
hardware
cursor first every time a new one is set.  This is needed because
hardware
may be able to handle some cursors in harware and others not, or virtual
hardware may be able to handle hardware cursors at some times and not
others.

Signed-off-by: Michael Thayer 
---
Checked the current git source and this change is still needed.  This
is an
updated patch which takes into account changes in the driver source since
the original patch was created.  Note that other than building I have not
had a chance to test that the updated patch still works, but the
difference
against the original is pretty minimal.

 hw/xfree86/drivers/modesetting/drmmode_display.c | 36
+---
 hw/xfree86/drivers/modesetting/drmmode_display.h |  1 -
 2 files changed, 13 insertions(+), 24 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 6b933e4..ad39f76 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -756,33 +756,23 @@ drmmode_set_cursor(xf86CrtcPtr crtc)
 drmmode_ptr drmmode = drmmode_crtc->drmmode;
 uint32_t handle = drmmode_crtc->cursor_bo->handle;
 modesettingPtr ms = modesettingPTR(crtc->scrn);
+CursorPtr cursor = xf86CurrentCursor(crtc->scrn->pScreen);
 int ret;

-if (!drmmode_crtc->set_cursor2_failed) {
-CursorPtr cursor = xf86CurrentCursor(crtc->scrn->pScreen);
-
-ret =
-drmModeSetCursor2(drmmode->fd,
drmmode_crtc->mode_crtc->crtc_id,
-  handle, ms->cursor_width,
ms->cursor_height,
-  cursor->bits->xhot, cursor->bits->yhot);
-if (!ret)
-return TRUE;
-
-drmmode_crtc->set_cursor2_failed = TRUE;
-}
-
-ret = drmModeSetCursor(drmmode->fd,
drmmode_crtc->mode_crtc->crtc_id, handle,
-   ms->cursor_width, ms->cursor_height);
+ret =
+drmModeSetCursor2(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
+  handle, ms->cursor_width, ms->cursor_height,
+  cursor->bits->xhot, cursor->bits->yhot);
+if (!ret)
+return TRUE;

-if (ret) {
-xf86CrtcConfigPtr xf86_config =
XF86_CRTC_CONFIG_PTR(crtc->scrn);
-xf86CursorInfoPtr cursor_info = xf86_config->cursor_info;
+/* -EINVAL can mean bad cursor parameters or Cursor2 API not
supported. */
+if (ret == -EINVAL)


You're reintroducing the -EINVAL check which was deliberately dropped
recently because sometimes another error is given while the non 2 version
might still work, please drop this bit.


I see that the commit message to 074cf587 states that sometimes ENXIO can be 
returned.  Sorry if I am being blind here (it would not be the first time), but 
I cannot see which path that could happen in.  It also seems a bit silly to 
unconditionally call drmModeSetCursor() every time drmModeSetCursor2() fails if 
it can be reasonably avoided.


I advise you to (directly) mail the author of that commit
perhaps he can explain things.

> So if I am being blind, would it be alright if I made the test (ret == 
-EINVAL || ret == ENXIO)?  Not that it would bring the world to an end, but still.

IIRC then during the review it was brought up that there
might be other errors to, e.g. I've seen checks for
-ENOSYS for other ioctls in some Xorg code. So I think
it is probably safest to just always try the fallback.

Regards,

Hans








Regards,

Michael


Also please actually test the patch before posting a new version.

Other then that this looks like an ok change to me.

Regards,

Hans




+ret = drmModeSetCursor(drmmode->fd,
drmmode_crtc->mode_crtc->crtc_id, handle,
+   ms->cursor_width, ms->cursor_height);

-cursor_info->MaxWidth = cursor_info->MaxHeight = 0;
-drmmode_crtc->drmmode->sw_cursor = TRUE;
-/* fallback to swcursor */
-return FALSE;
-}
+if (ret)
+return FALSE; /* fallback to swcursor */
 return TRUE;
 }

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h
b/hw/xfree86/drivers/modesetting/drmmode_display.h
index 50976b8..5170bf5 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.h
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
@@ -92,7 +92,6 @@ typedef struct {
 int dpms_mode;
 struct dumb_bo *cursor_bo;
 Bool cursor_up;
-Bool set_cursor2_failed;
 Bool first_cursor_load_done;
 uint16_t lut_r[256], lut_g[256], lut_b[256];





___
xorg-devel@lists.x.org: X.Org development
Archives: 

Re: [PATCH xserver v2] xfree86: recognize primary BUS_PCI device in xf86IsPrimaryPlatform()

[Laszlo Ersek]

On 09/07/16 17:15, Hans de Goede wrote:
> Hi,
> 
> On 07-09-16 15:08, Laszlo Ersek wrote:
>> The new platform bus code and the old PCI bus code overlap. Platform bus
>> can handle any type of device, including PCI devices, whereas the PCI
>> code
>> can only handle PCI devices. Some drivers only support the old style
>> PCI-probe methods, but the primary device detection code is server based,
>> not driver based; so we might end up with a primary device which only has
>> a PCI bus-capable driver, but was detected as primary by the platform
>> code, or the other way around.
>>
>> (The above paragraph was shamelessly stolen from Hans de Goede, and
>> customized.)
>>
>> The latter case applies to QEMU's virtio-gpu-pci device: it is
>> detected as
>> a BUS_PCI primary device, but we actually probe it first (with the
>> modesetting driver) through xf86platformProbeDev(). The
>> xf86IsPrimaryPlatform() function doesn't recognize the device as primary
>> (it bails out as soon as it sees BUS_PCI); instead, we add the device
>> as a
>> secondary graphics card under "autoAddGPU". In turn, the success of this
>> automatic probing-as-GPU prevents xf86CallDriverProbe() from
>> proceeding to
>> the PCI probing.
>>
>> The result is that the server exits with no primary devices detected.
>>
>> Commit cf66471353ac ("xfree86: use udev to provide device enumeration for
>> kms devices (v10)") added "cross-bus" matching to xf86IsPrimaryPci().
>> Port
>> that now to xf86IsPrimaryPlatform(), so that we can probe virtio-gpu-pci
>> as a primary card in platform bus code.
>>
>> Cc: Adam Jackson 
>> Cc: Dave Airlie 
>> Cc: Hans de Goede 
>> Cc: Keith Packard 
>> Cc: Marcin Juszkiewicz 
>> Signed-off-by: Laszlo Ersek 
> 
> Patch looks good to me:
> 
> Reviewed-by: Hans de Goede 

Many kudos to you Hans and Marcin (and everyone else who participated)
for your continued help / support / testing with this issue.

Since it's been one week since the last message in this thread, and the
v2 patch is both reviewed and tested, I thought I'd send a ping about
merging the patch. (I checked both the master branch in git and the pull
requests in the September ML archive; I don't see the patch in either.)

I hope it's not too early (other projects I'm involved with accept /
encourage a ping after a week of silence). Apologies if it's too early.

So, "ping" :)

Thanks!
Laszlo


>> ---
>>
>> Notes:
>> - F24 scratch build:
>>   
>>
>> - Marcin, can you please test this too on your phys hw setup? Thanks!
>>
>>  hw/xfree86/common/xf86platformBus.c | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/xfree86/common/xf86platformBus.c
>> b/hw/xfree86/common/xf86platformBus.c
>> index 96895a6e17f4..71f8df1d7681 100644
>> --- a/hw/xfree86/common/xf86platformBus.c
>> +++ b/hw/xfree86/common/xf86platformBus.c
>> @@ -114,7 +114,15 @@ xf86_find_platform_device_by_devnum(int major,
>> int minor)
>>  static Bool
>>  xf86IsPrimaryPlatform(struct xf86_platform_device *plat)
>>  {
>> -return ((primaryBus.type == BUS_PLATFORM) && (plat ==
>> primaryBus.id.plat));
>> +if (primaryBus.type == BUS_PLATFORM)
>> +return plat == primaryBus.id.plat;
>> +#ifdef XSERVER_LIBPCIACCESS
>> +if (primaryBus.type == BUS_PCI)
>> +if (plat->pdev)
>> +if (MATCH_PCI_DEVICES(primaryBus.id.pci, plat->pdev))
>> +return TRUE;
>> +#endif
>> +return FALSE;
>>  }
>>
>>  static void
>>

___
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] config: fix GPUDevice fail when AutoAddGPU off + BusID

[Michel Dänzer]

On 08/09/16 10:24 PM, Qiang Yu wrote:
> This fix is for the following xorg.conf can work:
> 
> Section "ServerFlags"
> Option  "AutoAddGPU" "off"
> EndSection
> 
> Section "Device"
> Identifier "Amd"
> Driver "ati"
> BusID "PCI:1:0:0"
> EndSection
> 
> Section "Device"
> Identifier "Intel"
> Driver "modesetting"
> BusID "pci:0:2:0"
> EndSection
> 
> Section "Screen"
> Identifier "Screen0"
> Device "Intel"
> GPUDevice "Amd"
> EndSection
> 
> Without AutoAddGPU off, modesetting DDX will also be loaded
> for GPUDevice.
> 
> Signed-off-by: Qiang Yu 
> ---
>  hw/xfree86/common/xf86platformBus.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/xfree86/common/xf86platformBus.c 
> b/hw/xfree86/common/xf86platformBus.c
> index 96895a6..03fd931 100644
> --- a/hw/xfree86/common/xf86platformBus.c
> +++ b/hw/xfree86/common/xf86platformBus.c
> @@ -418,6 +418,19 @@ probeSingleDevice(struct xf86_platform_device *dev, 
> DriverPtr drvp, GDevPtr gdev
>  return foundScreen;
>  }
>  
> +static Bool
> +isGPUDevice(GDevPtr gdev)
> +{
> +int i;
> +
> +for (i = 0; i < gdev->myScreenSection->num_gpu_devices; i++) {
> +if (gdev == gdev->myScreenSection->gpu_devices[i])
> +return TRUE;
> +}
> +
> +return FALSE;
> +}
> +
>  int
>  xf86platformProbeDev(DriverPtr drvp)
>  {
> @@ -450,9 +463,8 @@ xf86platformProbeDev(DriverPtr drvp)
>  if (j == xf86_num_platform_devices)
>   continue;
>  
> -foundScreen = probeSingleDevice(_platform_devices[j], drvp, 
> devList[i], 0);
> -if (!foundScreen)
> -continue;
> +foundScreen = probeSingleDevice(_platform_devices[j], drvp, 
> devList[i],
> +isGPUDevice(devList[i]) ? 
> PLATFORM_PROBE_GPU_SCREEN : 0);

The last line is a bit long, maybe move "PLATFORM_PROBE_GPU_SCREEN : 0"
to the next line. Either way,

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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: [xserver PULL master] Modesetting driver prime fixes (unreviewed)

[Hans de Goede]

Hi,

On 13-09-16 17:45, Adam Jackson wrote:

On Tue, 2016-09-13 at 12:53 +0200, Hans de Goede wrote:


The following changes since commit 35c4e96ed1d372dd161480be8cddcd2d4549e449:

   randr: Fix crtc_bounds when using rotation combined with reflection 
(2016-09-13 10:27:30 +0200)

are available in the git repository at:

   git://people.freedesktop.org/~jwrdegoede/xserver modesetting-prime-fixes

for you to fetch changes up to 08cfeecd524729589cd6b7c6e6fe65211b268dae:

   modesetting: Fall back to primary crtc for vblank for drawables on slave 
outputs (2016-09-13 12:40:13 +0200)


Reviewed


Thank you!


and merged:


And thank you again :)


remote: I: patch #105350 updated using rev 
03a7c50202f61030830ff639fccf52091e02156c.
remote: I: patch #105352 updated using rev 
238248d67e6a422f31e8864c0b15d693a658cdac.
remote: I: patch #107096 updated using rev 
7ade8ba10e1e767bb510343c86573bc5d4804b92.
remote: I: patch #107269 updated using rev 
d8e05c04758cbcd7b5c11362cb28ce017d50098b.
remote: I: 4 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   35c4e96..d8e05c0  master -> master

But if I may ask:



Hans de Goede (4):
   modesetting: ms_dri2_create_buffer: check screen of existing front 
buffers


This change doesn't look like it can hurt, but I'm wondering why it's
necessary. How does this come up?


I don't think it does, but I was not 100% sure, I based the DRIInforec v9 
callbacks
work on the nouveau driver and that had this check, so I added it under a 
better safe
then sorry philosophy.

Regards,

Hans
___
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: allow switching from software to hardware cursors.

[Hans de Goede]

Hi,

On 13-09-16 17:42, Michael Thayer wrote:

Currently if modesetting ever fails to set a hardware cursor it will switch
to using a software cursor and never go back.  Change this to try a hardware
cursor first every time a new one is set.  This is needed because hardware
may be able to handle some cursors in harware and others not, or virtual
hardware may be able to handle hardware cursors at some times and not others.

Signed-off-by: Michael Thayer 
---
Checked the current git source and this change is still needed.  This is an
updated patch which takes into account changes in the driver source since
the original patch was created.  Note that other than building I have not
had a chance to test that the updated patch still works, but the difference
against the original is pretty minimal.

 hw/xfree86/drivers/modesetting/drmmode_display.c | 36 +---
 hw/xfree86/drivers/modesetting/drmmode_display.h |  1 -
 2 files changed, 13 insertions(+), 24 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 6b933e4..ad39f76 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -756,33 +756,23 @@ drmmode_set_cursor(xf86CrtcPtr crtc)
 drmmode_ptr drmmode = drmmode_crtc->drmmode;
 uint32_t handle = drmmode_crtc->cursor_bo->handle;
 modesettingPtr ms = modesettingPTR(crtc->scrn);
+CursorPtr cursor = xf86CurrentCursor(crtc->scrn->pScreen);
 int ret;

-if (!drmmode_crtc->set_cursor2_failed) {
-CursorPtr cursor = xf86CurrentCursor(crtc->scrn->pScreen);
-
-ret =
-drmModeSetCursor2(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
-  handle, ms->cursor_width, ms->cursor_height,
-  cursor->bits->xhot, cursor->bits->yhot);
-if (!ret)
-return TRUE;
-
-drmmode_crtc->set_cursor2_failed = TRUE;
-}
-
-ret = drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, 
handle,
-   ms->cursor_width, ms->cursor_height);
+ret =
+drmModeSetCursor2(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
+  handle, ms->cursor_width, ms->cursor_height,
+  cursor->bits->xhot, cursor->bits->yhot);
+if (!ret)
+return TRUE;

-if (ret) {
-xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
-xf86CursorInfoPtr cursor_info = xf86_config->cursor_info;
+/* -EINVAL can mean bad cursor parameters or Cursor2 API not supported. */
+if (ret == -EINVAL)


You're reintroducing the -EINVAL check which was deliberately dropped
recently because sometimes another error is given while the non 2 version
might still work, please drop this bit.

Also please actually test the patch before posting a new version.

Other then that this looks like an ok change to me.

Regards,

Hans




+ret = drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, 
handle,
+   ms->cursor_width, ms->cursor_height);

-cursor_info->MaxWidth = cursor_info->MaxHeight = 0;
-drmmode_crtc->drmmode->sw_cursor = TRUE;
-/* fallback to swcursor */
-return FALSE;
-}
+if (ret)
+return FALSE; /* fallback to swcursor */
 return TRUE;
 }

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h 
b/hw/xfree86/drivers/modesetting/drmmode_display.h
index 50976b8..5170bf5 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.h
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
@@ -92,7 +92,6 @@ typedef struct {
 int dpms_mode;
 struct dumb_bo *cursor_bo;
 Bool cursor_up;
-Bool set_cursor2_failed;
 Bool first_cursor_load_done;
 uint16_t lut_r[256], lut_g[256], lut_b[256];



___
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: weird Xwayland and compositor deadlock issue [WAS: [PATCH xserver v2] xwayland: handle EAGAIN and EINTR gracefully]

[Pekka Paalanen]

On Tue, 13 Sep 2016 12:04:14 -0400 (EDT)
Olivier Fourdan  wrote:

> Hi Pekka,
> 
> - Original Message -
> > Hi Olivier,
> > 
> > I don't have any solution for you. The interactions between the Wayland
> > compositor and Xwayland are known to be very easily deadlockable IIRC. I
> > believe the only thing you can do is ensure no such case can ever
> > occur, which is very painful. That is, never do a blocking roundtrip at
> > least from one side.
> > 
> > Have the recent modifications caused a significant increase of Wayland
> > requests from Xwayland? If Xwayland needs to send an amount of data
> > bigger than bufferable, *any* blocking roundtrip via X11 from the
> > Wayland compositor is prone to deadlock. It will be waiting for a reply
> > via X11, while Xwayland is blocked on flushing, since the Wayland
> > compositor is not consuming requests.
> > 
> > It can also trivially happen if both sides do a blocking roundtrip at
> > the same time. Or just a wait for an event.
> > 
> > Either server needs to be able to return to its main loop to process the
> > protocol stream it is the server for. Preferably both, I think.  
> 
> Unfortunately, any XSync (like, for example, called in
> gdk_error_trap_pop() in gdk) will issue a blocking roundtrip, and
> window managers tend to do that quite a lot (some more than others)
> so I don't think we can easily chaneg that in window managers to
> avoid blocking rountrips on X11 side.
> 
> > You could check how Weston's XWM works. I highly suspect that after
> > Xwayland launch it avoids doing any blocking roundtrips via X11.  
> 
> Yet sometimes some X calls are blocking, e.g. XShapeGetRectangles()
> or even XGetWindowAttributes() which is invoked by mutter each time
> the a new window is mapped. mutter still uses Xlib and not xcb.
> 
> > I'd assume Xwayland also tries to avoid blocking on Wayland events,
> > but if nothing else, I believe Mesa via GLAMOR may block on
> > wl_buffer.release events... or maybe not if GLAMOR is smart with its
> > throttling. Anyway, since your flush is hitting EAGAIN, that doesn't
> > seem to be the cause.
> > 
> > I wonder if making wl_display_flush() block immediately like in your
> > patch could be replaced by adding the wl_display fd to the main poll
> > loop, so that it would get flushed ASAP but still service X11
> > requests in the mean time? It does run the risk of overflowing the
> > Wayland send buffer in Xwayland. Any way to prioritize the Wayland
> > compositor's X11 connection in Xwayland?  
> 
> If I don't make EAGAIN a FatalError() and wait for the Wayland
> display file descriptor to become writable again, Xwayland eventually
> dies with another error "(EE) request could not be marshaled: can't
> send file descriptor" from libwayland directly (in
> copy_fds_to_connection()).

Hi,

summarizing from #wayland irc between Olivier and Daniel: the proper
solution is indeed to never do blocking X11 roundtrips from the Wayland
compositor, but for practical reasons that might not be possible.

The irc log starts here:
https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=wayland_names==2016-09-13#t-1402


Thanks,
pq


pgpDxk59uUIfK.pgp
Description: OpenPGP digital 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

Re: [PATCH vmmouse] conf: rename to 70-vmmouse.conf

[Peter Hutterer]

On Mon, Jun 13, 2016 at 03:31:13PM +1000, Peter Hutterer wrote:
> On Fri, Jun 10, 2016 at 04:32:19PM +0200, Stefan Dirsch wrote:
> > Bump up the vmmouse driver to 70, so it get's preferred over libinput, which
> > was dropped down to 60. This is only relevant for older kernels, which do 
> > not
> > yet have the functionality provided by vmmouse driver. On recent kernels
> > vmmouse driver is no longer loaded at all.
> > 
> > Signed-off-by: Stefan Dirsch 
> 
> Reviewed-by: Peter Hutterer 

fwiw, this patch is obsolete now that libinput was bumped back to
40-libinput.

Cheers,
   Peter

> > ---
> >  tools/{50-vmmouse.conf => 70-vmmouse.conf} | 0
> >  tools/Makefile.am  | 2 +-
> >  2 files changed, 1 insertion(+), 1 deletion(-)
> >  rename tools/{50-vmmouse.conf => 70-vmmouse.conf} (100%)
> > 
> > diff --git a/tools/50-vmmouse.conf b/tools/70-vmmouse.conf
> > similarity index 100%
> > rename from tools/50-vmmouse.conf
> > rename to tools/70-vmmouse.conf
> > diff --git a/tools/Makefile.am b/tools/Makefile.am
> > index da0e782..0b4c526 100644
> > --- a/tools/Makefile.am
> > +++ b/tools/Makefile.am
> > @@ -41,7 +41,7 @@ CLEANFILES = hal-probe-vmmouse
> >  if HAS_XORG_CONF_DIR
> >  
> >  confdir=$(XORG_CONF_DIR)
> > -dist_conf_DATA = 50-vmmouse.conf
> > +dist_conf_DATA = 70-vmmouse.conf
> >  
> >  endif
> >  
> > -- 
> > 2.6.6
___
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: Proposed X server 1.19 schedule

[Keith Packard]

Keith Packard  writes:

> [ Unknown signature status ]
>
> Following the 'release early and often' mantra, we should probably get
> 1.19 out the door and let people start using the new code.
>
> I'd like to propose that we figure out what remaining non-bug changes
> we'd like to get merged in the next week (or two?), then move into a
> non-critical bug fix period for two weeks followed by three or four
> weeks of critical bug fixing and testing. That would look like:
>
> Development cycle ends: 2016-9-10

Ok, we're a few days past this, and we still have some outstanding
changes which haven't been merged in:

 1) An Xwayland feature request for dealing with cursor warping. This
one needs review, at least for the ABI changes.

 2) SyncSharedPixmap hook in the screen. This has been reviewed.

 3) Set primary output in xf86RandR12CreateScreenResources12. This one
has also been reviewed already.

If someone wants to review the Xwayland changes, that'd be great. I can
merge the two reviewed patches (2 and 3), unless Michel beats me to it.

There are also some fixes for Xephyr which Laércio has posted but which
haven't yet seen review. I'm comfortable having these merged during the
non-critical bug window if someone wants to take a look.

Please let me know if you have other changes (other than bug fixes)
which need to be considered for 1.19. Otherwise, I think we can cut RC1
soon.

Adam asked that we move the non-critical deadline to 10-1 and leave the
final release at 10-22, which seems fine to me.

That means

 Non-critical bugs:  2016-10-1
 Critical-bugs:  2016-10-22

-- 
-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

[PATCH xserver] config/dbus: Initialize dbus fd to -1 so teardown doesn't use fd 0

[Keith Packard]

The dbus teardown code is called when the server fatal errors even if
that is before dbus has ever been initialized.  By statically
initializing the value of bus_info.fd, we avoid calling RemoveNotifyFd
on stdin.

Signed-off-by: Keith Packard 
---
 config/dbus-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config/dbus-core.c b/config/dbus-core.c
index 3c85ad7..6d9a3f9 100644
--- a/config/dbus-core.c
+++ b/config/dbus-core.c
@@ -43,7 +43,7 @@ struct dbus_core_info {
 OsTimerPtr timer;
 struct dbus_core_hook *hooks;
 };
-static struct dbus_core_info bus_info;
+static struct dbus_core_info bus_info = { .fd = -1 };
 
 static CARD32 reconnect_timer(OsTimerPtr timer, CARD32 time, void *arg);
 
-- 
2.8.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