[PATCH] glamor: Fix XvPutImage when src_y != 0

2016-02-10 Thread Hans de Goede 
We already take src_y into account when uploading the src data by
starting at the top line of the src data when uploading.

Adjust src_y accordingly when rendering.

Signed-off-by: Hans de Goede 
---
 glamor/glamor_xv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/glamor/glamor_xv.c b/glamor/glamor_xv.c
index 9ac60af..3bcf909 100644
--- a/glamor/glamor_xv.c
+++ b/glamor/glamor_xv.c
@@ -495,7 +495,7 @@ glamor_xv_put_image(glamor_port_private *port_priv,
 RegionCopy(_priv->clip, clipBoxes);
 
 port_priv->src_x = src_x;
-port_priv->src_y = src_y;
+port_priv->src_y = src_y - top;
 port_priv->src_w = src_w;
 port_priv->src_h = src_h;
 port_priv->dst_w = drw_w;
-- 
2.5.0

___
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: Hybrid graphics - "radeon" driver unloaded, "modesetting" loaded?

2016-02-10 Thread Michel Dänzer 
On 10.02.2016 23:43, Alex Deucher wrote:
> On Wed, Feb 10, 2016 at 7:58 AM, Lennert Van Alboom
>  wrote:
>> On Fri, Feb 05, 2016 at 11:24:12AM +0900, Michel Dänzer wrote:
>>> On 04.02.2016 19:05, Lennert Van Alboom wrote:
 Hello. I've got a HP Elitebook 850g1 with hybrid graphics:

 $ lspci | grep VGA
 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT 
 Integrated Graphics Controller (rev 0b)
 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
 [AMD/ATI] Mars [Radeon HD 8730M] (rev ff)

 $ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
 0:IGD:+:Pwr::00:02.0
 1:DIS-Audio: :Off::03:00.1
 2:DIS: :DynOff::03:00.0

 I'm running Debian (sid, x86_64) with kernel 4.4.0-trunk-amd64 (same 
 happens with the 4.3.0-1-amd64 kernel) and Xorg 1:7.7+13 (1.18.0).
 I'm having an odd issue where Xorg loads the correct "radeon" driver, but 
 after a split second, unloads it again and loads "modesetting":

 [13.688] (II) config/udev: removing GPU device 
 /sys/devices/pci:00/:00:1c.4/:03:00.0/drm/card1 /dev/dri/card1
 [13.688] xf86: remove device 1 
 /sys/devices/pci:00/:00:1c.4/:03:00.0/drm/card1
 [13.693] (II) UnloadModule: "radeon"
 [13.693] (II) UnloadSubModule: "fb"
 [13.693] (II) Unloading fb
 [13.693] (II) UnloadSubModule: "glamoregl"
 [13.693] (II) Unloading glamoregl
 [13.693] (II) config/udev: Adding drm device (/dev/dri/card1)
 [13.693] (II) xfree86: Adding drm device (/dev/dri/card1)
 [13.693] (II) LoadModule: "modesetting"
 [13.693] (II) Loading 
 /usr/lib/xorg/modules/drivers/modesetting_drv.so

 Full Xorg log at http://ziff.soleus.nu/Xorg.0.log.txt. I don't have a 
 xorg.conf, and no snippets in xorg.conf.d either.

 This results in two providers in xrandr, Intel and modesetting (as opposed 
 to radeon, as I had before):

 $ xrandr --listproviders
 Providers: number : 2
 Provider 0: id: 0x7d cap: 0xb, Source Output, Sink Output, Sink 
 Offload crtcs: 4 outputs: 6 associated providers: 0 name:Intel
 Provider 1: id: 0x140 cap: 0x3, Source Output, Sink Output crtcs: 2 
 outputs: 2 associated providers: 0 name:modesetting

 I can't set an offload sink:

 $ xrandr --setprovideroffloadsink modesetting Intel
 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:  34 (RRSetProviderOffloadSink)
 Value in failed request:  0x140
 Serial number of failed request:  16
 Current serial number in output stream:  17

 And, I suppose this is normal because of the above, DRI_PRIME doesn't do 
 much:

 $ glxinfo | grep "OpenGL renderer"
 OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
 $ DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
 OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile

 Strangely enough, the /sys device link for "card1", as mentioned in the 
 Xorg log, still points to the "correct" ATI device:

 $ ls -l /sys/class/drm/card1/device
 lrwxrwxrwx 1 root root 0 Feb  3 21:14 /sys/class/drm/card1/device -> 
 ../../../:03:00.0


 I'm a bit stumped here. How can I get my radeon device back in the xrandr 
 providers and working via DRI_PRIME?
>>>
>>> I can see two problems here: Xorg unloads the radeon driver and loads
>>> the modesetting driver instead, and the modesetting driver doesn't
>>> advertise PRIME render offloading capability. I don't think either is a
>>> radeon driver issue though, so the xorg-devel list seems more
>>> appropriate. Moving there.
>>
>>
>> Okay. The second problem isn't much of a problem (for me, personally) if the
>> first gets resolved, so I suppose it makes sense to look at that first.
>>
>> Why would Xorg unload a valid driver for a card and load another instead? 
>> And,
>> more to the point, is there a way of preventing it from happening?
> 
> Possibly an old version of the driver that is missing the pci id for
> the asic you have.

That's not consistent with the log file: The radeon driver loads and
fully initializes successfully, but then for some reason (apparently
udev related), the radeon driver is unloaded and the modesetting driver
is loaded instead for the Radeon GPU.


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

Re: Hybrid graphics - "radeon" driver unloaded, "modesetting" loaded?

2016-02-10 Thread Alex Deucher 
On Wed, Feb 10, 2016 at 7:58 AM, Lennert Van Alboom
 wrote:
> On Fri, Feb 05, 2016 at 11:24:12AM +0900, Michel Dänzer wrote:
>> On 04.02.2016 19:05, Lennert Van Alboom wrote:
>> > Hello. I've got a HP Elitebook 850g1 with hybrid graphics:
>> >
>> > $ lspci | grep VGA
>> > 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT 
>> > Integrated Graphics Controller (rev 0b)
>> > 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
>> > [AMD/ATI] Mars [Radeon HD 8730M] (rev ff)
>> >
>> > $ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
>> > 0:IGD:+:Pwr::00:02.0
>> > 1:DIS-Audio: :Off::03:00.1
>> > 2:DIS: :DynOff::03:00.0
>> >
>> > I'm running Debian (sid, x86_64) with kernel 4.4.0-trunk-amd64 (same 
>> > happens with the 4.3.0-1-amd64 kernel) and Xorg 1:7.7+13 (1.18.0).
>> > I'm having an odd issue where Xorg loads the correct "radeon" driver, but 
>> > after a split second, unloads it again and loads "modesetting":
>> >
>> > [13.688] (II) config/udev: removing GPU device 
>> > /sys/devices/pci:00/:00:1c.4/:03:00.0/drm/card1 /dev/dri/card1
>> > [13.688] xf86: remove device 1 
>> > /sys/devices/pci:00/:00:1c.4/:03:00.0/drm/card1
>> > [13.693] (II) UnloadModule: "radeon"
>> > [13.693] (II) UnloadSubModule: "fb"
>> > [13.693] (II) Unloading fb
>> > [13.693] (II) UnloadSubModule: "glamoregl"
>> > [13.693] (II) Unloading glamoregl
>> > [13.693] (II) config/udev: Adding drm device (/dev/dri/card1)
>> > [13.693] (II) xfree86: Adding drm device (/dev/dri/card1)
>> > [13.693] (II) LoadModule: "modesetting"
>> > [13.693] (II) Loading 
>> > /usr/lib/xorg/modules/drivers/modesetting_drv.so
>> >
>> > Full Xorg log at http://ziff.soleus.nu/Xorg.0.log.txt. I don't have a 
>> > xorg.conf, and no snippets in xorg.conf.d either.
>> >
>> > This results in two providers in xrandr, Intel and modesetting (as opposed 
>> > to radeon, as I had before):
>> >
>> > $ xrandr --listproviders
>> > Providers: number : 2
>> > Provider 0: id: 0x7d cap: 0xb, Source Output, Sink Output, Sink 
>> > Offload crtcs: 4 outputs: 6 associated providers: 0 name:Intel
>> > Provider 1: id: 0x140 cap: 0x3, Source Output, Sink Output crtcs: 2 
>> > outputs: 2 associated providers: 0 name:modesetting
>> >
>> > I can't set an offload sink:
>> >
>> > $ xrandr --setprovideroffloadsink modesetting Intel
>> > 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:  34 (RRSetProviderOffloadSink)
>> > Value in failed request:  0x140
>> > Serial number of failed request:  16
>> > Current serial number in output stream:  17
>> >
>> > And, I suppose this is normal because of the above, DRI_PRIME doesn't do 
>> > much:
>> >
>> > $ glxinfo | grep "OpenGL renderer"
>> > OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
>> > $ DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
>> > OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
>> >
>> > Strangely enough, the /sys device link for "card1", as mentioned in the 
>> > Xorg log, still points to the "correct" ATI device:
>> >
>> > $ ls -l /sys/class/drm/card1/device
>> > lrwxrwxrwx 1 root root 0 Feb  3 21:14 /sys/class/drm/card1/device -> 
>> > ../../../:03:00.0
>> >
>> >
>> > I'm a bit stumped here. How can I get my radeon device back in the xrandr 
>> > providers and working via DRI_PRIME?
>>
>> I can see two problems here: Xorg unloads the radeon driver and loads
>> the modesetting driver instead, and the modesetting driver doesn't
>> advertise PRIME render offloading capability. I don't think either is a
>> radeon driver issue though, so the xorg-devel list seems more
>> appropriate. Moving there.
>>
>>
>> --
>> Earthling Michel Dänzer   |   http://www.amd.com
>> Libre software enthusiast | Mesa and X developer
>
>
> Okay. The second problem isn't much of a problem (for me, personally) if the
> first gets resolved, so I suppose it makes sense to look at that first.
>
> Why would Xorg unload a valid driver for a card and load another instead? And,
> more to the point, is there a way of preventing it from happening?

Possibly an old version of the driver that is missing the pci id for
the asic you have.

Alex
___
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] xwayland: Use drm buffers for cursors if available

2016-02-10 Thread Emil Velikov 
Hi all,

Just a small note:

On 5 February 2016 at 08:42, Pekka Paalanen  wrote:

> umm, do we really want to add even more uses of the Mesa-private wl_drm
> protocol outside of Mesa? Though it seems that ship sailed a long time
> ago.
>
> Should we just bite the bullet, and have Mesa install drm.xml for
> public consumption? Or move drm.xml to wayland-protocols.git?
>
> I thought all that was a Bad Idea(tm).
>
If we consider that distributing the protocol for public consumption
is OK, please use wayland-protocols.git. Keeping it in mesa will lead
to nasty circular dependencies.

Thanks
Emil
___
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] xwayland: Use drm buffers for cursors if available

2016-02-10 Thread Kristian Høgsberg 
On Wed, Feb 10, 2016 at 7:39 AM, Emil Velikov  wrote:
> Hi all,
>
> Just a small note:
>
> On 5 February 2016 at 08:42, Pekka Paalanen  wrote:
>
>> umm, do we really want to add even more uses of the Mesa-private wl_drm
>> protocol outside of Mesa? Though it seems that ship sailed a long time
>> ago.
>>
>> Should we just bite the bullet, and have Mesa install drm.xml for
>> public consumption? Or move drm.xml to wayland-protocols.git?
>>
>> I thought all that was a Bad Idea(tm).
>>
> If we consider that distributing the protocol for public consumption
> is OK, please use wayland-protocols.git. Keeping it in mesa will lead
> to nasty circular dependencies.

I think we should. It's pretty much the equivalent of dri2proto and
it's useful for projects such as libva as well.

> Thanks
> Emil
___
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] dri2: Use the work queue to manage client sleeps

2016-02-10 Thread Adam Jackson 
In  commit e43abdce964f5ed9689cf908af8c305b39a5dd36
Author: Chris Wilson 
Date:   Wed Feb 3 09:54:46 2016 +

dri2: Unblock Clients on Drawable release

we try to wake up any blocked clients at drawable destruction. But by
the time we get there, CloseDownConnection has already torn down state
that AttendClient wants to modify.

Using ClientSleep instead of IgnoreClient puts a wakeup function on a
workqueue, and the queue will be cleared for us in CloseDownClient
before (non-neverretain) resource teardown.

Cc: Chris Wilson 
Cc: Ville Syrjälä 
Signed-off-by: Adam Jackson 
---
 hw/xfree86/dri2/dri2.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index dfc2f49..30ac1a7 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -260,8 +260,7 @@ DRI2SwapLimit(DrawablePtr pDraw, int swap_limit)
 
 if (pPriv->target_sbc == -1 && !pPriv->blockedOnMsc) {
 if (pPriv->blockedClient) {
-AttendClient(pPriv->blockedClient);
-pPriv->blockedClient = NULL;
+ClientSignal(pPriv->blockedClient);
 }
 }
 
@@ -414,7 +413,7 @@ DRI2DrawableGone(void *p, XID id)
 }
 
 if (pPriv->blockedClient)
-AttendClient(pPriv->blockedClient);
+ClientSignal(pPriv->blockedClient);
 
 free(pPriv);
 
@@ -690,6 +689,15 @@ DRI2InvalidateDrawable(DrawablePtr pDraw)
 ref->invalidate(pDraw, ref->priv, ref->id);
 }
 
+static Bool
+dri2ClientWake(ClientPtr client, void *closure)
+{
+DRI2DrawablePtr pPriv = closure;
+ClientWakeup(client);
+pPriv->blockedClient = NULL;
+return TRUE;
+}
+
 /*
  * In the direct rendered case, we throttle the clients that have more
  * than their share of outstanding swaps (and thus busy buffers) when a
@@ -710,7 +718,7 @@ DRI2ThrottleClient(ClientPtr client, DrawablePtr pDraw)
 if ((pPriv->swapsPending >= pPriv->swap_limit) && !pPriv->blockedClient) {
 ResetCurrentRequest(client);
 client->sequence--;
-IgnoreClient(client);
+ClientSleep(client, dri2ClientWake, pPriv);
 pPriv->blockedClient = client;
 return TRUE;
 }
@@ -722,7 +730,7 @@ static void
 __DRI2BlockClient(ClientPtr client, DRI2DrawablePtr pPriv)
 {
 if (pPriv->blockedClient == NULL) {
-IgnoreClient(client);
+ClientSleep(client, dri2ClientWake, pPriv);
 pPriv->blockedClient = client;
 }
 }
@@ -971,9 +979,8 @@ DRI2WaitMSCComplete(ClientPtr client, DrawablePtr pDraw, 
int frame,
  frame, pPriv->swap_count);
 
 if (pPriv->blockedClient)
-AttendClient(pPriv->blockedClient);
+ClientSignal(pPriv->blockedClient);
 
-pPriv->blockedClient = NULL;
 pPriv->blockedOnMsc = FALSE;
 }
 
@@ -983,7 +990,7 @@ DRI2WakeClient(ClientPtr client, DrawablePtr pDraw, int 
frame,
 {
 ScreenPtr pScreen = pDraw->pScreen;
 DRI2DrawablePtr pPriv;
-
+t
 pPriv = DRI2GetDrawable(pDraw);
 if (pPriv == NULL) {
 xf86DrvMsg(pScreen->myNum, X_ERROR,
@@ -1003,14 +1010,11 @@ DRI2WakeClient(ClientPtr client, DrawablePtr pDraw, int 
frame,
 ProcDRI2WaitMSCReply(client, ((CARD64) tv_sec * 100) + tv_usec,
  frame, pPriv->swap_count);
 pPriv->target_sbc = -1;
-
-AttendClient(pPriv->blockedClient);
-pPriv->blockedClient = NULL;
+ClientSignal(pPriv->blockedClient);
 }
 else if (pPriv->target_sbc == -1 && !pPriv->blockedOnMsc) {
 if (pPriv->blockedClient) {
-AttendClient(pPriv->blockedClient);
-pPriv->blockedClient = NULL;
+ClientSignal(pPriv->blockedClient);
 }
 }
 }
-- 
2.5.0

___
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] xwayland: Use drm buffers for cursors if available

2016-02-10 Thread Daniel Stone 
On 10 February 2016 at 17:08, Kristian Høgsberg  wrote:
> On Wed, Feb 10, 2016 at 7:39 AM, Emil Velikov  
> wrote:
>> On 5 February 2016 at 08:42, Pekka Paalanen  wrote:
>>
>>> umm, do we really want to add even more uses of the Mesa-private wl_drm
>>> protocol outside of Mesa? Though it seems that ship sailed a long time
>>> ago.
>>>
>>> Should we just bite the bullet, and have Mesa install drm.xml for
>>> public consumption? Or move drm.xml to wayland-protocols.git?
>>>
>>> I thought all that was a Bad Idea(tm).
>>>
>> If we consider that distributing the protocol for public consumption
>> is OK, please use wayland-protocols.git. Keeping it in mesa will lead
>> to nasty circular dependencies.
>
> I think we should. It's pretty much the equivalent of dri2proto and
> it's useful for projects such as libva as well.

Why not a stabliised zlinux_dmabuf instead? The only thing I can
really say against it is that it lacks FB modifier support, but, well,
so does wl_drm (and gbm, which means you can't extract multi-plane
buffers to overlays, or particularly sensibly to
non-TEXTURE_EXTERNAL_OES GL ...).

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 kdrive/ephyr v7 3/9] kdrive: introduce input hot-plugging support for udev and hal backends (#33140)

2016-02-10 Thread Laércio de Sousa 
2016-02-08 17:45 GMT-02:00 Adam Jackson :
>
> This introduces a warning:
>
> kdrive.c:1217:1: warning: no previous prototype for
> 'systemd_logind_release_fd' [-Wmissing-prototypes]
>  systemd_logind_release_fd(int _major, int _minor, int fd)
>  ^
> kdrive.c:1222:1: warning: no previous prototype for
> 'systemd_logind_vtenter' [-Wmissing-prototypes]
>  systemd_logind_vtenter(void)

 ^
>
OK. I've just introduced the prototypes in kdrive.c itself (so I don't need
to #include ). These warnings are now gone.

This seems like the sort of comment where the act of writing it is a
> sign that the code must be wrong.  Why is RemoveDevice not closing the
> fd for you?
>
I'm not sure why it happens, but without this "redundant" check around
RemoveDevice(), if I unplug the mouse, replug it and start moving it,
Xephyr segfaults.
-- 
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
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 kdrive/ephyr v7 4/9] kdrive: update evdev keyboard LEDs (#22302)

2016-02-10 Thread Laércio de Sousa 
This is the output of command "xinput list" for my latest Xephyr in
multi-seat mode *without* this patch applied.

⎡ Virtual core pointer id=2 [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer   id=4 [slave  pointer  (2)]
⎜   ↳ SIGMACHIP Usb Mouse id=6 [slave  pointer  (2)]
⎣ Virtual core keyboard   id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave  keyboard (3)]
↳ HID 04f3:0103   id=7 [slave  keyboard (3)]

In this scenario, when I toggle NumLock or CapsLock, the keyboard reacts as
expected (I mean, I can enable CapsLock and start typing capital letters,
and I can enable NumLock and start typing numbers in my num pad), but the
keyboard LED's are always *off*.

2016-02-08 17:52 GMT-02:00 Adam Jackson :

> On Fri, 2015-12-11 at 11:43 -0200, Laércio de Sousa wrote:
> > From: Mikhail Krivtsov 
> >
> > When one hits {Num,Caps,Scroll}Lock key on a Xephyr's keyboard,
> > keyboard itself works as expected but LEDs are not updated
> > and always stay in off.
> >
> > Currently logical LEDs are propagated to physical keyboard LEDs
> > for "CoreKeyboard" only. All "kdrive" keyboards are not
> > "CoreKeyboard" and LEDs of "kdrive" keyboards are always "dead".
> >
> > One possible solution is cloning "CoreKeyboard" LEDs to all
> > "kdrive" keyboards.
>
> Can you describe this scenario better?  What does the output of 'xinput
> list' look like when you encounter this?
>
> - ajax
>



-- 
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
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] xwayland: Use drm buffers for cursors if available

2016-02-10 Thread Jasper St. Pierre 
I don't necessarily have an opinion either way, but do note that since
VGEM isn't here yet, this change will break using Xwayland under a
free VM. We should fall back to wl_shm in any case.

On Wed, Feb 10, 2016 at 9:16 AM, Daniel Stone  wrote:
> On 10 February 2016 at 17:08, Kristian Høgsberg  wrote:
>> On Wed, Feb 10, 2016 at 7:39 AM, Emil Velikov  
>> wrote:
>>> On 5 February 2016 at 08:42, Pekka Paalanen  wrote:
>>>
 umm, do we really want to add even more uses of the Mesa-private wl_drm
 protocol outside of Mesa? Though it seems that ship sailed a long time
 ago.

 Should we just bite the bullet, and have Mesa install drm.xml for
 public consumption? Or move drm.xml to wayland-protocols.git?

 I thought all that was a Bad Idea(tm).

>>> If we consider that distributing the protocol for public consumption
>>> is OK, please use wayland-protocols.git. Keeping it in mesa will lead
>>> to nasty circular dependencies.
>>
>> I think we should. It's pretty much the equivalent of dri2proto and
>> it's useful for projects such as libva as well.
>
> Why not a stabliised zlinux_dmabuf instead? The only thing I can
> really say against it is that it lacks FB modifier support, but, well,
> so does wl_drm (and gbm, which means you can't extract multi-plane
> buffers to overlays, or particularly sensibly to
> non-TEXTURE_EXTERNAL_OES GL ...).
>
> 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



-- 
  Jasper
___
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 12/12 v3] xwayland: add partial xvidmode extension support

2016-02-10 Thread Olivier Fourdan 
Older games (mostly those based on SDL 1.x) rely on the XVidMode
extension and would refuse to run without.

Add a simple, limited and read-only xvidmode support that reports the
current mode used so that games that rely on xvidmode extension can run
on XWayland.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87806
Signed-off-by: Olivier Fourdan 
---
 v2: Pretend Set/GetGamma work so that OpenArena can run in Xwayland
 v3: Check HSync/VRefresh/HTotal/VTotal to accept the mode we advertised
 Register xwlVidModePrivateKey() only once in xwlVidModeExtensionInit()
 
 hw/xwayland/Makefile.am|   2 +
 hw/xwayland/xwayland-vidmode.c | 409 +
 hw/xwayland/xwayland.c |   8 +
 hw/xwayland/xwayland.h |   4 +
 4 files changed, 423 insertions(+)
 create mode 100644 hw/xwayland/xwayland-vidmode.c

diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am
index ab1bbb6..0905082 100644
--- a/hw/xwayland/Makefile.am
+++ b/hw/xwayland/Makefile.am
@@ -16,6 +16,7 @@ Xwayland_SOURCES =\
xwayland-shm.c  \
xwayland-output.c   \
xwayland-cvt.c  \
+   xwayland-vidmode.c  \
xwayland.h  \
$(top_srcdir)/Xext/dpmsstubs.c  \
$(top_srcdir)/Xi/stubs.c\
@@ -25,6 +26,7 @@ Xwayland_LDADD =  \
$(glamor_lib)   \
$(XWAYLAND_LIBS)\
$(XWAYLAND_SYS_LIBS)\
+   $(top_builddir)/Xext/libXvidmode.la \
$(XSERVER_SYS_LIBS)
 Xwayland_LDFLAGS = $(LD_EXPORT_SYMBOLS_FLAG)
 
diff --git a/hw/xwayland/xwayland-vidmode.c b/hw/xwayland/xwayland-vidmode.c
new file mode 100644
index 000..e31eeaa
--- /dev/null
+++ b/hw/xwayland/xwayland-vidmode.c
@@ -0,0 +1,409 @@
+/*
+ * Copyright (c) 1999-2003 by The XFree86 Project, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Except as contained in this notice, the name of the copyright holder(s)
+ * and author(s) shall not be used in advertising or otherwise to promote
+ * the sale, use or other dealings in this Software without prior written
+ * authorization from the copyright holder(s) and author(s).
+ */
+
+#ifdef HAVE_DIX_CONFIG_H
+#include 
+#endif
+
+#include 
+#include "misc.h"
+#include "os.h"
+#include "extinit.h"
+
+#ifdef XF86VIDMODE
+#include "xwayland.h"
+#include "randrstr.h"
+#include "vidmodestr.h"
+
+static DevPrivateKeyRec xwlVidModePrivateKeyRec;
+#define xwlVidModePrivateKey ()
+
+/* Taken from xrandr, h sync frequency in KHz */
+static double
+mode_hsync(const xRRModeInfo *mode_info)
+{
+double rate;
+
+if (mode_info->hTotal)
+rate = (double) mode_info->dotClock / (double) mode_info->hTotal;
+else
+rate = 0.0;
+
+return rate / 1000.0;
+}
+
+/* Taken from xrandr, v refresh frequency in Hz */
+static double
+mode_refresh(const xRRModeInfo *mode_info)
+{
+double rate;
+double vTotal = mode_info->vTotal;
+
+if (mode_info->modeFlags & RR_DoubleScan)
+   vTotal *= 2.0;
+
+if (mode_info->modeFlags & RR_Interlace)
+   vTotal /= 2.0;
+
+if (mode_info->hTotal > 0.0 && vTotal > 0.0)
+   rate = ((double) mode_info->dotClock /
+   ((double) mode_info->hTotal * (double) vTotal));
+else
+rate = 0.0;
+
+return rate;
+}
+
+static Bool
+xwlVidModeGetCurrentModeline(ScreenPtr pScreen, DisplayModePtr *mode, int 
*dotClock)
+{
+DisplayModePtr pMod;
+RROutputPtr output;
+RRCrtcPtr crtc;
+xRRModeInfo rrmode;
+
+pMod = dixLookupPrivate(>devPrivates, xwlVidModePrivateKey);
+if (pMod == NULL)
+return FALSE;
+
+output = RRFirstOutput(pScreen);
+if (output == NULL)
+return FALSE;
+
+crtc =

[PATCH xserver 2/2] dix: Disable AttendClient() operation during client teardown

2016-02-10 Thread Chris Wilson 
commit e43abdce964f5ed9689cf908af8c305b39a5dd36
Author: Chris Wilson 
Date:   Wed Feb 3 09:54:46 2016 +

dri2: Unblock Clients on Drawable release

added a call to AttendClient during drawable teardown, which also happens
as a result of client teardown. However, at that point the Client state
is no longer valid causing a possible explosion from AttendClient().

A simple workaround is to set the Client as ignored when tearing it
down, but we then also need to teach AttendClient not to dereference its
private pointer during teardown.

References: Jos van Wolput 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94074
Testcase: dri2-race/client
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Adam Jackson 
---
 dix/dispatch.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/dix/dispatch.c b/dix/dispatch.c
index 53032dc..bfb5e1a 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -3414,6 +3414,9 @@ CloseDownClient(ClientPtr client)
 }
 
 if (really_close_down) {
+/* The client is going away, disable any AttendClient during shutdown 
*/
+client->ignoreCount++;
+
 if (client->clientState == ClientStateRunning && nClients == 0)
 dispatchException |= dispatchExceptionAtReset;
 
-- 
2.7.0

___
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 1/2] os: Move OsCommPtr dereference after ignoreCount check

2016-02-10 Thread Chris Wilson 
Make AttendClient safe to call along the client teardown path (i.e.
after CloseDownConnection which is called before the Client's resources
are freed) by checking the ClientPtr before the OsCommPtr.

References: https://bugs.freedesktop.org/show_bug.cgi?id=94074
Signed-off-by: Chris Wilson 
Cc: Adam Jackson 
---
 os/connection.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/os/connection.c b/os/connection.c
index 4c1ba4b..be3e4d1 100644
--- a/os/connection.c
+++ b/os/connection.c
@@ -1254,12 +1254,13 @@ void
 IgnoreClient(ClientPtr client)
 {
 OsCommPtr oc = (OsCommPtr) client->osPrivate;
-int connection = oc->fd;
+int connection;
 
 client->ignoreCount++;
 if (client->ignoreCount > 1)
 return;
 
+connection = oc->fd;
 isItTimeToYield = TRUE;
 if (!GrabInProgress || FD_ISSET(connection, )) {
 if (FD_ISSET(connection, ))
@@ -1291,12 +1292,13 @@ void
 AttendClient(ClientPtr client)
 {
 OsCommPtr oc = (OsCommPtr) client->osPrivate;
-int connection = oc->fd;
+int connection;
 
 client->ignoreCount--;
 if (client->ignoreCount)
 return;
 
+connection = oc->fd;
 if (!GrabInProgress || GrabInProgress == client->index ||
 FD_ISSET(connection, )) {
 FD_SET(connection, );
-- 
2.7.0

___
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: Hybrid graphics - "radeon" driver unloaded, "modesetting" loaded?

2016-02-10 Thread Lennert Van Alboom 
On Fri, Feb 05, 2016 at 11:24:12AM +0900, Michel Dänzer wrote:
> On 04.02.2016 19:05, Lennert Van Alboom wrote:
> > Hello. I've got a HP Elitebook 850g1 with hybrid graphics:
> > 
> > $ lspci | grep VGA
> > 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT 
> > Integrated Graphics Controller (rev 0b)
> > 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
> > [AMD/ATI] Mars [Radeon HD 8730M] (rev ff)
> > 
> > $ sudo cat /sys/kernel/debug/vgaswitcheroo/switch 
> > 0:IGD:+:Pwr::00:02.0
> > 1:DIS-Audio: :Off::03:00.1
> > 2:DIS: :DynOff::03:00.0
> > 
> > I'm running Debian (sid, x86_64) with kernel 4.4.0-trunk-amd64 (same 
> > happens with the 4.3.0-1-amd64 kernel) and Xorg 1:7.7+13 (1.18.0).
> > I'm having an odd issue where Xorg loads the correct "radeon" driver, but 
> > after a split second, unloads it again and loads "modesetting":
> > 
> > [13.688] (II) config/udev: removing GPU device 
> > /sys/devices/pci:00/:00:1c.4/:03:00.0/drm/card1 /dev/dri/card1
> > [13.688] xf86: remove device 1 
> > /sys/devices/pci:00/:00:1c.4/:03:00.0/drm/card1
> > [13.693] (II) UnloadModule: "radeon"
> > [13.693] (II) UnloadSubModule: "fb"
> > [13.693] (II) Unloading fb
> > [13.693] (II) UnloadSubModule: "glamoregl"
> > [13.693] (II) Unloading glamoregl
> > [13.693] (II) config/udev: Adding drm device (/dev/dri/card1)
> > [13.693] (II) xfree86: Adding drm device (/dev/dri/card1)
> > [13.693] (II) LoadModule: "modesetting"
> > [13.693] (II) Loading 
> > /usr/lib/xorg/modules/drivers/modesetting_drv.so
> > 
> > Full Xorg log at http://ziff.soleus.nu/Xorg.0.log.txt. I don't have a 
> > xorg.conf, and no snippets in xorg.conf.d either.
> > 
> > This results in two providers in xrandr, Intel and modesetting (as opposed 
> > to radeon, as I had before):
> > 
> > $ xrandr --listproviders
> > Providers: number : 2
> > Provider 0: id: 0x7d cap: 0xb, Source Output, Sink Output, Sink Offload 
> > crtcs: 4 outputs: 6 associated providers: 0 name:Intel
> > Provider 1: id: 0x140 cap: 0x3, Source Output, Sink Output crtcs: 2 
> > outputs: 2 associated providers: 0 name:modesetting
> > 
> > I can't set an offload sink:
> > 
> > $ xrandr --setprovideroffloadsink modesetting Intel
> > 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:  34 (RRSetProviderOffloadSink)
> > Value in failed request:  0x140
> > Serial number of failed request:  16
> > Current serial number in output stream:  17
> > 
> > And, I suppose this is normal because of the above, DRI_PRIME doesn't do 
> > much:
> > 
> > $ glxinfo | grep "OpenGL renderer"
> > OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
> > $ DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
> > OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
> > 
> > Strangely enough, the /sys device link for "card1", as mentioned in the 
> > Xorg log, still points to the "correct" ATI device:
> > 
> > $ ls -l /sys/class/drm/card1/device
> > lrwxrwxrwx 1 root root 0 Feb  3 21:14 /sys/class/drm/card1/device -> 
> > ../../../:03:00.0
> > 
> > 
> > I'm a bit stumped here. How can I get my radeon device back in the xrandr 
> > providers and working via DRI_PRIME?
> 
> I can see two problems here: Xorg unloads the radeon driver and loads
> the modesetting driver instead, and the modesetting driver doesn't
> advertise PRIME render offloading capability. I don't think either is a
> radeon driver issue though, so the xorg-devel list seems more
> appropriate. Moving there.
> 
> 
> -- 
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer


Okay. The second problem isn't much of a problem (for me, personally) if the
first gets resolved, so I suppose it makes sense to look at that first. 

Why would Xorg unload a valid driver for a card and load another instead? And,
more to the point, is there a way of preventing it from happening? 



Lennert


signature.asc
Description: 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 kdrive/ephyr v7 3/9] kdrive: introduce input hot-plugging support for udev and hal backends (#33140)

2016-02-10 Thread Peter Hutterer 
On Mon, Feb 08, 2016 at 02:45:43PM -0500, Adam Jackson wrote:
> On Fri, 2015-12-11 at 11:43 -0200, Laércio de Sousa wrote:
> 
> > +void
> > +systemd_logind_release_fd(int _major, int _minor, int fd)
> > +{
> > +}
> > +
> > +void
> > +systemd_logind_vtenter(void)
> > +{
> > +}
> 
> This introduces a warning:
> 
> kdrive.c:1217:1: warning: no previous prototype for 
> 'systemd_logind_release_fd' [-Wmissing-prototypes]
>  systemd_logind_release_fd(int _major, int _minor, int fd)
>  ^
> kdrive.c:1222:1: warning: no previous prototype for 'systemd_logind_vtenter' 
> [-Wmissing-prototypes]
>  systemd_logind_vtenter(void)
>  ^
>  
> > @@ -2230,5 +2348,55 @@ NewInputDeviceRequest(InputOption *options, 
> > InputAttributes * attrs,
> >  void
> >  DeleteInputDeviceRequest(DeviceIntPtr pDev)
> >  {
> > +#if defined(CONFIG_UDEV) || defined(CONFIG_HAL)
> > +OsBlockSIGIO();
> >  RemoveDevice(pDev, TRUE);
> > +
> > +/*
> > + * Search for fds that were not unregistered correctly
> > + * by RemoveDevice() call and unregister them.
> > + * Code taken from KdInputDisable() implementation.
> > + */
> 
> This seems like the sort of comment where the act of writing it is a
> sign that the code must be wrong.  Why is RemoveDevice not closing the
> fd for you?

we don't have a 1:1 mapping between devices and fd (e.g. wacom devices all
hang off a single fd). Even the fd itself is a DDX concept, so RemoveDevice
cannot close the fd.

What should happen here though is that the pDev->public.devicePrivate points
to something kdrive understands and that includes the fd.

Cheers,
   Peter
___
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 kdrive/ephyr v7 4/9] kdrive: update evdev keyboard LEDs (#22302)

2016-02-10 Thread Peter Hutterer 
On Fri, Dec 11, 2015 at 11:43:09AM -0200, Laércio de Sousa wrote:
> From: Mikhail Krivtsov 
> 
> When one hits {Num,Caps,Scroll}Lock key on a Xephyr's keyboard,
> keyboard itself works as expected but LEDs are not updated
> and always stay in off.
> 
> Currently logical LEDs are propagated to physical keyboard LEDs
> for "CoreKeyboard" only. All "kdrive" keyboards are not
> "CoreKeyboard" and LEDs of "kdrive" keyboards are always "dead".
> 
> One possible solution is cloning "CoreKeyboard" LEDs to all
> "kdrive" keyboards.
> 
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=22302
> 
> Signed-off-by: Laércio de Sousa 
> ---
>  hw/kdrive/linux/evdev.c | 11 ---
>  hw/kdrive/src/kinput.c  | 23 +++
>  2 files changed, 31 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/kdrive/linux/evdev.c b/hw/kdrive/linux/evdev.c
> index 63e8409..fecbae4 100644
> --- a/hw/kdrive/linux/evdev.c
> +++ b/hw/kdrive/linux/evdev.c
> @@ -440,10 +440,16 @@ EvdevKbdEnable(KdKeyboardInfo * ki)
>  static void
>  EvdevKbdLeds(KdKeyboardInfo * ki, int leds)
>  {
> -/*struct input_event event;
> +struct input_event event;
>  Kevdev *ke;
> +if (!ki) return; // This shouldn't happen but just for safety.

no // comments please, and our indenting style is 4 spaces.
>  
> -ki->driverPrivate = ke;
> +ke = ki->driverPrivate;
> +if (!ke) {
> + ErrorF("[%s:%u:%s] can't update LEDs of _disabled_ evdev keyboard\n",
> + __FILE__, __LINE__, __FUNCTION__);
> + return;
> +}
>  
>  memset(, 0, sizeof(event));
>  
> @@ -466,7 +472,6 @@ EvdevKbdLeds(KdKeyboardInfo * ki, int leds)
>  event.code = LED_COMPOSE;
>  event.value = leds & (1 << 3) ? 1 : 0;
>  write(ke->fd, (char *) , sizeof(event));
> -*/
>  }
>  
>  static void
> diff --git a/hw/kdrive/src/kinput.c b/hw/kdrive/src/kinput.c
> index 682b63a..e9a5f24 100644
> --- a/hw/kdrive/src/kinput.c
> +++ b/hw/kdrive/src/kinput.c
> @@ -618,6 +618,28 @@ KdSetLed(KdKeyboardInfo * ki, int led, Bool on)
>  KdSetLeds(ki, ki->dixdev->kbdfeed->ctrl.leds);
>  }
>  
> +/*
> + * For unknown reason, logical keyboard LEDs are propagated to physical
> + * keyboard LEDs for "CoreKeyboard" only. All "kdrive" keyboards are
> + * not "CoreKeyboard" and LEDs of "kdrive" keyboards are always "dead".
> + * As workaround, the following function will clone "CoreKeyboard" LEDs
> + * to all "kdrive" keyboards.
> + */

the idea behind only propagating LED changes to core keyboard is that you
may have multiple keyboards, not all attached to the same master keyboard.
If you toggle caps lock on one of them, you don't want it to toggle on an
otherwise unrelated keyboard. Likewise, there's the niche case of floating
slave devices, where you don't want logical keyboard LEDs to change other
keyboards.

> +static void
> +KdCloneCoreLEDs(void)
> +{
> +DeviceIntPtr pCoreKeyboard = inputInfo.keyboard;
> +if (pCoreKeyboard && pCoreKeyboard->kbdfeed) {
> +   Leds leds = pCoreKeyboard->kbdfeed->ctrl.leds;
> +   KdKeyboardInfo *tmp;
> +   for (tmp = kdKeyboards; tmp; tmp = tmp->next) {
> +   if (tmp->leds != leds) {
> +KdSetLeds(tmp, tmp->leds = leds);
^^ this almost certainly doesn't
do what you want.


so something else isn't right here. By default, xephyr keyboards should be
attached to a master keyboard and see the LEDs update. Where exactly does
the LED update stop?

Cheers,
   Peter

> +   }
> +}
> +}
> +}
> +
>  void
>  KdSetPointerMatrix(KdPointerMatrix * matrix)
>  {
> @@ -2163,6 +2185,7 @@ ProcessInputEvents(void)
>  if (kdSwitchPending)
>  KdProcessSwitch();
>  KdCheckLock();
> +KdCloneCoreLEDs();
>  }
>  
>  /* At the moment, absolute/relative is up to the client. */
> -- 
> 2.1.4
___
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