Re: Proposed X server 1.19 schedule

2016-09-14 Thread 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

2016-09-14 Thread 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

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

2016-09-14 Thread 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

[Bug 97810] Boot Kernel Panic RX460 (polaris11)

2016-09-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97810

--- Comment #1 from Alexis  ---
CPU : AMD A10 7800
GPU : Gigabyte Radeon RX 460 WindForce OC - 2 Gb
Motherboard : GA-F2A78M-HD2
8 Gb RAM DDR3

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 97810] New: Boot Kernel Panic RX460 (polaris11)

2016-09-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97810

Bug ID: 97810
   Summary: Boot Kernel Panic RX460 (polaris11)
   Product: xorg
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Driver/AMDgpu
  Assignee: xorg-driver-ati@lists.x.org
  Reporter: alexis.ro...@gmail.com
QA Contact: xorg-t...@lists.x.org

Created attachment 126528
  --> https://bugs.freedesktop.org/attachment.cgi?id=126528=edit
capture of kernel panic on boot

On libreelec builds (kernel 4.7.3 or 4.8rc6, mesa 12.0.2 i guess), kernel panic
on boot, refering to the amdgpu : early init of IP block (amdgpu_powerplay)
failed -22

Screen capture attached

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

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

2016-09-14 Thread 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: damage.c wrapping bug?

2016-09-14 Thread Adam Jackson 
On Wed, 2016-09-14 at 14:01 -0400, Stirling Westrup wrote:
> I'm currently reading through the source for the damage extension in
> damage.c and I noticed that the list of functions that get wrapped
> when a screen gets damage support is not the same as the list of
> functions that get unwrapped when the screen is closed. That is
> DamageSetup() wraps these functions:
> 
>  DestroyPixmap   -> damageDestroyPixmap  
>  CreateGC    -> damageCreateGC  
>  DestroyWindow   -> damageDestroyWindow  
>  SetWindowPixmap -> damageSetWindowPixmap  
>  CopyWindow  -> damageCopyWindow  
>  CloseScreen -> damageCloseScreen   
> 
> but inside damageCloseScreen, the list of functions that get restored
> are:
> 
>  DestroyPixmap
>  CreateGC
>  CopyWindow
>  CloseScreen
> 
> and neither SetWindowPixmap nor DestroyWindow are ever unwrapped. Is
> this an issue, or is there some reason to believe this isn't a
> problem?

It's a bug, though it's probably harmless. On the next generation
fbScreenInit (or whatever the bottom dispatch layer happens to be) is
going to reinitialize those slots in the ScreenRec, and since it's the
bottom layer it's not going to wrap them but just install them.

- 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

damage.c wrapping bug?

2016-09-14 Thread Stirling Westrup 
I'm currently reading through the source for the damage extension in
damage.c and I noticed that the list of functions that get wrapped when a
screen gets damage support is not the same as the list of functions that
get unwrapped when the screen is closed. That is DamageSetup() wraps these
functions:

 DestroyPixmap   -> damageDestroyPixmap
 CreateGC-> damageCreateGC
 DestroyWindow   -> damageDestroyWindow
 SetWindowPixmap -> damageSetWindowPixmap
 CopyWindow  -> damageCopyWindow
 CloseScreen -> damageCloseScreen

but inside damageCloseScreen, the list of functions that get restored are:

 DestroyPixmap
 CreateGC
 CopyWindow
 CloseScreen

and neither SetWindowPixmap nor DestroyWindow are ever unwrapped. Is this
an issue, or is there some reason to believe this isn't a problem?

-- 
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup
___
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] modesetting: allow switching from software to hardware cursors.

2016-09-14 Thread 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:

[PATCH xserver v3] xwayland: handle EAGAIN on Wayland fd

2016-09-14 Thread 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: RandR 1.5 Monitors: "No monitor named '...'"

2016-09-14 Thread Aaron Plattner 
On 09/11/2016 08:29 PM, Nathan Schulte wrote:
> I'm using X.org w/ Debian Sid:
> 
>> nmschulte@desmas-l:~$ Xorg -version
>>
>> X.Org X Server 1.18.4
>> Release Date: 2016-07-19
>> X Protocol Version 11, Revision 0
>> Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
>> Current Operating System: Linux desmas-l 4.7.0-1-amd64 #1 SMP Debian
>> 4.7.2-1 (2016-08-28) x86_64
>> Kernel command line: BOOT_IMAGE=/vmlinuz-4.7.0-1-amd64
>> root=UUID=f5ba8b5c-63aa-4a67-a07c-dd8d3297b2d3 ro quiet
>> i915.enable_dp_mst=0
>> Build Date: 06 September 2016  01:32:44PM
>> xorg-server 2:1.18.4-2 (https://www.debian.org/support)
>> Current version of pixman: 0.33.6
>> Before reporting problems, check http://wiki.x.org
>> to make sure that you have the latest version.
> 
> I'm playing around with the new Monitors support which came with RandR
> 1.5 support.  Thanks for this awesome kit; it's extremely useful, and
> awesome that there's full-stack support for this virtualization concept
> finally.
> 
> Anyway, it seems I've been able to make RandR very confused; I cannot
> delete a monitor which xrandr tells me exists:
> 
>> nmschulte@desmas-l:~$ xrandr --listmonitors
>> Monitors: 2
>>  0: +*eDP1 1920/340x1080/190+0+0  eDP1
>>  1: dp2_0 0/0x0/0+0+0
>> nmschulte@desmas-l:~$ xrandr --delmonitor dp2_0
>> No monitor named 'dp2_0'
>> nmschulte@desmas-l:~$ xrandr --setmonitor dp2_0 auto eDP1
>> output list eDP1
>> add monitor eDP1
>> output name eDP1
>> X Error of failed request:  BadValue (integer parameter out of range
>> for operation)
>>   Major opcode of failed request:  140 (RANDR)
>>   Minor opcode of failed request:  43 ()
>>   Value in failed request:  0x2c0
>>   Serial number of failed request:  43
>>   Current serial number in output stream:  44
>> nmschulte@desmas-l:~$ xrandr --listmonitors
>> Monitors: 2
>>  0: +*eDP1 1920/340x1080/190+0+0  eDP1
>>  1: dp2_0 0/0x0/0+0+0
> 
> Below is my setup; this is on a laptop with Intel Haswell / Intel HD
> 4600 graphics, as well as an AMD Radeon HD 8970M gpu (no heads; render
> offload hybrid graphics setup).
> 
>> nmschulte@desmas-l:~$ xrandr
>> Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
>> eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y
>> axis) 340mm x 190mm
>>1920x1080 60.00*+  59.9350.00
>>1680x1050 59.9559.88
>>1600x1024 60.17
>>1400x1050 59.98
>>1600x900  60.00
>>1280x1024 60.02
>>1440x900  59.89
>>1280x960  60.00
>>1368x768  60.00
>>1360x768  59.8059.96
>>1152x864  60.00
>>1280x720  60.00
>>1024x768  60.00
>>1024x576  60.00
>>960x540   60.00
>>800x600   60.3256.25
>>864x486   60.00
>>640x480   59.94
>>720x405   60.00
>>640x360   60.00
>> DP1 disconnected (normal left inverted right x axis y axis)
>> DP2 disconnected (normal left inverted right x axis y axis)
>> HDMI1 disconnected (normal left inverted right x axis y axis)
>> HDMI2 disconnected (normal left inverted right x axis y axis)
>> HDMI3 disconnected (normal left inverted right x axis y axis)
>> VIRTUAL1 disconnected (normal left inverted right x axis y axis)
> 
> Also, can anyone explain the VIRTUAL1 output?  I wonder why it exists,
> what purpose it serves.
> 
> As well, this laptop "only" has three external output connectors; on
> mini DisplayPort, one DisplayPort, and one HDMI.  Do the two other HDMI
> outputs show in the list because the DisplayPort connectors are
> dual-mode DisplayPort / DisplayPort++?  If so, is there any part of the
> stack that can communicate this (to user-space)?  I don't believe it's
> possible to use the HDMI and DP outputs at the same time for a single
> DP++ port, so it's somewhat confusing that they're listed in the list,
> if what I'm suggesting above is the case.

There is supposed to be a "ConnectorNumber" property that you can use to
correlate these RandR outputs with physical connectors.

https://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt?id=cf3272717e08325f69bdbb759ab35cb4d1839fb7#n1931

E.g., on my system, these two are halves of the same mini-DisplayPort
connector:

DP-0 connected 1920x1200+0+960 (normal left inverted right x axis y
axis) 518mm x 324mm
_MUTTER_PRESENTATION_OUTPUT: 0
CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0
EDID:
000010ac2ea055574a31
1b1201038034207891a3544c9926
0f5054a54b00714f8180a94001010101
010101010101283c80a070b023403020
36000644211a00ff00473237
3348383731314a57552000fc0044
454c4c20453234385746500a00fd
00384c1e5311000a20202020202b
BorderDimensions: 4
supported: 4
Border: 0 0 0 0
range: (0, 65535)
SignalFormat: TMDS
supported: TMDS

Xlib doc

2016-09-14 Thread Lucien Gentis 

Hello,

XRestackWindows function :

It is said in 
https://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html#Changing_Window_Stacking_Order 
:


"For each window in the window array that is not a child of the 
specified window, a BadMatch error results."


but in ftp://www.x.org/pub/X11R7.7/doc/man/man3/XRaiseWindow.3.xhtml 
(which is also a manpage for  XRestackWindows function) :


"For each window in the window array that is not a sibling of the first 
window, a BadMatch error results."




--
Lucien GENTIS
UNIVERSITE DE LORRAINE - ESPE
Centre de Ressources Informatiques
5, Rue Paul Richard
C.O. 3 - MAXEVILLE
54528 LAXOU-CEDEX

Tél. 03 72 74 13 28
Email : lucien.gen...@univ-lorraine.fr

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

2016-09-14 Thread 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

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

2016-09-14 Thread 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

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

2016-09-14 Thread 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

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

2016-09-14 Thread 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

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

2016-09-14 Thread 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: [xserver PULL master] Modesetting driver prime fixes (unreviewed)

2016-09-14 Thread 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

[Bug 97578] Radeon HD 5450 suddenly blanks screen or shows old content

2016-09-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97578

--- Comment #17 from Michel Dänzer  ---
(In reply to Markus Näher from comment #15)
> Well ... I asked about xorg.conf.d because there is no xorg.conf on my PC's.
> As far as I understand, this means my X server is autoconfigured [...]

Yep, that doesn't change what I said. :)


> As your name looks like it could be german (and hopefully you live in
> europe), I could send you the left 5450 via mail.
> This could be easier (for both of us) than you advising me how to test and
> possibly debug.

My last name is German (though I'm Swiss), but I'm currently living outside of
Europe. Anyway, I do have a 5xxx card, the problem is "just" finding the time
to try and reproduce and fix the problem; I'm afraid it's not very high
priority for me.

Anyway, since the problem doesn't happen with a 7750, it's quite possible that
using glamor will avoid it with a 5450 as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 90910] Switching workspaces in AwesomeWM - workspace changes but Awesome lags behind

2016-09-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=90910

--- Comment #2 from Paul Menzel  ---
Do you also experience the problem, when maximizing a Firefox window on a
screen with several Firefox windows, and when demaximizing it, the background
is not updated?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 97578] Radeon HD 5450 suddenly blanks screen or shows old content

2016-09-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97578

--- Comment #16 from Markus Näher  ---
Created attachment 126510
  --> https://bugs.freedesktop.org/attachment.cgi?id=126510=edit
XFCE compositor settings

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 97578] Radeon HD 5450 suddenly blanks screen or shows old content

2016-09-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97578

--- Comment #14 from Michel Dänzer  ---
(In reply to Markus Näher from comment #13)
> How do I set it in xorg.conf.d ?

You don't. :) xorg.conf.d is for system configuration snippets, users should
always use /etc/X11/xorg.conf directly. Something like this should do:

Section "Device"
Identifier  "default"
Driver  "radeon"
Option  "AccelMethod" "glamor"
EndSection


> Disabling compositing seems to help. No occurrences so far today.

Can you attach screenshots of all XFCE settings tabs containing any compositing
related settings?

--- Comment #15 from Markus Näher  ---
Well ... I asked about xorg.conf.d because there is no xorg.conf on my PC's. As
far as I understand, this means my X server is autoconfigured except a few
things in my xorg.conf.d. Currenntly, it's only keyboard settings and dual
screen positions (DVI-1 right of DVI-0).

I'm trying your proposed settings as soon as my current long running job is
done. It runs in a GUI app, so I can't even restart X.

About the radeon-git package ... as I said, it is flagged as outdated, but I
found out it's even worse ... the maintainer abandoned it. So I'm afraid I
won't be able to install the git version.
But I have another idea: I was lucky to find a cheap used Radeon HD 7750 with
passive cooling, so one of my two PC's does not have the problem anymore, and
one of the 5450's is now left over.
As your name looks like it could be german (and hopefully you live in europe),
I could send you the left 5450 via mail.
This could be easier (for both of us) than you advising me how to test and
possibly debug.

If that's OK for you, you can contact me via the EMail link on my name and give
me your postal address.

I promise not to bother you :-)

Another interesting thing; When I re-enabled the compositor for making the
screenshot of the settings, the issue showed up immediately.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: weird Xwayland and compositor deadlock issue [WAS: [PATCH xserver v2] xwayland: handle EAGAIN and EINTR gracefully]

2016-09-14 Thread 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

[Bug 91922] [SUMO] Xorg Server crash on launch 3D application using DRI_PRIME, if GLAMOR is used as AccelMethod with radeon driver

2016-09-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=91922

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #8 from Michel Dänzer  ---
Should be fixed in xf86-video-ati Git master:

commit e91858e435672c32f9c4a854b3dec048199d6f7f
Author: Michel Dänzer 
Date:   Mon Sep 12 18:02:07 2016 +0900

glamor: Fix radeon_glamor_share_pixmap_backing for priv->bo == NULL

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: [PATCH xserver] config: fix GPUDevice fail when AutoAddGPU off + BusID

2016-09-14 Thread 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