Re: [PATCH v3 0/9] PRIME Synchronization

[Michel Dänzer]

On 24.02.2016 12:05, Alex Goins wrote:
> Thanks for the reply, Dave!
> 
>> Is there any reason this only addresses one direction in the
>> -modesetting driver.
>>
>> In theory shouldn't we able to expose both source and sink bits in 
>> -modesetting?
>> (esp when glamor is enabled).
> 
> Yes, both source and sink bits could be exposed by modesetting via glamor. A
> public implementation of source support would be good to have in the future
> particularly for reverse PRIME, but the feature primarily benefits non-Mesa
> drivers and many users are eager to take advantage as soon as possible.

I already pointed out this issue over two months ago in
https://lists.freedesktop.org/archives/xorg-devel/2015-December/048215.html
. Seems like there's been plenty of time to address it.


> I'd like to move forward with the patches without source support in 
> modesetting.
> A fairly detailed explanation of the source functions can be found in the v2
> cover letter, if that will suffice.

FWIW, being able to test your series with the modesetting driver would
definitely make me much more comfortable about it.


-- 
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: [PATCH v3 0/9] PRIME Synchronization

[Alex Goins]

Thanks for the reply, Dave!

> Is there any reason this only addresses one direction in the
> -modesetting driver.
> 
> In theory shouldn't we able to expose both source and sink bits in 
> -modesetting?
> (esp when glamor is enabled).

Yes, both source and sink bits could be exposed by modesetting via glamor. A
public implementation of source support would be good to have in the future
particularly for reverse PRIME, but the feature primarily benefits non-Mesa
drivers and many users are eager to take advantage as soon as possible.

I'd like to move forward with the patches without source support in modesetting.
A fairly detailed explanation of the source functions can be found in the v2
cover letter, if that will suffice.

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

Possible regression/ABI breakage in Xorg socket-activation support

[Laércio de Sousa]

Hi there!

Regarging https://bugs.freedesktop.org/show_bug.cgi?id=93072, I've also
observed this issue in Ubuntu 15.10 (xorg-server 1.17.2 and systemd 225)
and 16.04 alpha 2 (xorg-server 1.17.3 and systemd 229), but not in openSUSE
Leap 42.1 (xorg-server 1.17.2 and systemd 210).

Could it be a Xorg regression? A systemd regression? Or some kind of
libsystemd ABI breakage?
___
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] kdrive/ephyr: map host X server's keymap into Xephyr, if supported

[Ran Benita]

On Tue, Feb 23, 2016 at 07:58:04AM -0300, Laércio de Sousa wrote:
> Currently Xephyr doesn't inherit host X server's keymap, which
> may lead to keymap mismatches when typing in a window inside
> Xephyr. If host X server supports XKB extension, this patch
> uses xcb-xkb to apply its keymap in Xephyr. This implementation
> is analogous to Xnest one at commit 83fef4235.
> 
> Supersedes: https://patchwork.freedesktop.org/patch/67504

I have zero context for this patch, but the subject piqued my curiosity,
since I know it is nigh impossible to upload an XKB keymap with current
xcb-xkb. And indeed, it seems you only use XKB here for the controls,
which include some repeat and accessibility info, but not the main
keymap data:
http://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#Global_Keyboard_Controls
The main calls are for the core protocol keymap.

So the sentence "If host X server supports XKB extension, this patch
uses xcb-xkb to apply its keymap in Xephyr." should be adjusted to only
talk about XKB controls and not the entire keymap, I think.

Ran
___
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: Unplugging the main graphics device

[Michael Thayer]

On 22.02.2016 21:29, Dave Airlie wrote:

On 22 February 2016 at 22:20, Michael Thayer  wrote:

On 19.02.2016 16:16, Michael Thayer wrote:


I have been experimenting a bit with plugging and unplugging of graphics
devices (using a dummy KMS driver which is udl stripped of the actual
hardware poking) and how the X server copes with that.  It seems to cope
well with a secondary device being removed, but not with the only
graphics device in the system disappearing (in that case the
hot-pluggable device is not deemed to be a GPU device, and therefore not
removable if I understood what is happening correctly).

[...]

Install driver, ask user to reboot.

Trying to remove the first screen from X is a long and insanity
inspiring process.

I've spent months hacking up something that lets us migrate stuff from screen A
to screen B, but it's really messy and the current X server code doesn't lend
itself to it at all, so I pretty much gave up the last time I tried.


Then perhaps having the place-holder first device in our kernel driver 
is a solution worth considering.  As the main person in charge of the 
kernel DRM tree, is that something you could live with?  I realise that 
making life easier for external drivers is not something which is 
normally done in the Linux kernel, but I think we have a valid reason 
for wanting to update the driver without updating the kernel.  We will 
probably need to go that way with our out-of-tree drivers anyway to 
support older kernel-and-X.Org combinations.


Or am I missing something here?  In theory this could also be done 
directly in the X server, and since you spent months working on this you 
probably already thought about something on these lines.


Regards,

Michael
--
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
___
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 kdrive/ephyr] kdrive/ephyr: map host X server's keymap into Xephyr, if supported

[Laércio de Sousa]

Currently Xephyr doesn't inherit host X server's keymap, which
may lead to keymap mismatches when typing in a window inside
Xephyr. If host X server supports XKB extension, this patch
uses xcb-xkb to apply its keymap in Xephyr. This implementation
is analogous to Xnest one at commit 83fef4235.

Supersedes: https://patchwork.freedesktop.org/patch/67504

Signed-off-by: Laércio de Sousa 
---
 configure.ac|   2 +-
 hw/kdrive/ephyr/ephyr.c |  30 ---
 hw/kdrive/ephyr/hostx.c | 131 +---
 hw/kdrive/ephyr/hostx.h |   9 +---
 hw/kdrive/src/kinput.c  |   8 +--
 5 files changed, 155 insertions(+), 25 deletions(-)

diff --git a/configure.ac b/configure.ac
index 312fc69..c166841 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2393,7 +2393,7 @@ if test "$KDRIVE" = yes; then
AC_DEFINE(KDRIVE_MOUSE, 1, [Enable KDrive mouse driver])
 fi
 
-XEPHYR_REQUIRED_LIBS="xau xdmcp xcb xcb-shape xcb-render xcb-renderutil 
xcb-aux xcb-image xcb-icccm xcb-shm xcb-keysyms xcb-randr"
+XEPHYR_REQUIRED_LIBS="xau xdmcp xcb xcb-shape xcb-render xcb-renderutil 
xcb-aux xcb-image xcb-icccm xcb-shm xcb-keysyms xcb-randr xcb-xkb"
 if test "x$XV" = xyes; then
 XEPHYR_REQUIRED_LIBS="$XEPHYR_REQUIRED_LIBS xcb-xv"
 fi
diff --git a/hw/kdrive/ephyr/ephyr.c b/hw/kdrive/ephyr/ephyr.c
index a272882..fa76765 100644
--- a/hw/kdrive/ephyr/ephyr.c
+++ b/hw/kdrive/ephyr/ephyr.c
@@ -47,7 +47,6 @@ extern Bool ephyr_glamor;
 
 KdKeyboardInfo *ephyrKbd;
 KdPointerInfo *ephyrMouse;
-EphyrKeySyms ephyrKeySyms;
 Bool ephyrNoDRI = FALSE;
 Bool ephyrNoXV = FALSE;
 
@@ -1291,16 +1290,35 @@ KdPointerDriver EphyrMouseDriver = {
 static Status
 EphyrKeyboardInit(KdKeyboardInfo * ki)
 {
+int i;
+KeySymsRec keySyms;
+CARD8 modmap[MAP_LENGTH];
+XkbControlsRec controls;
+
 ki->driverPrivate = (EphyrKbdPrivate *)
 calloc(sizeof(EphyrKbdPrivate), 1);
-hostx_load_keymap();
-if (!ephyrKeySyms.minKeyCode) {
+
+if (hostx_load_keymap(, modmap, )) {
+XkbApplyMappingChange(ki->dixdev, ,
+  keySyms.minKeyCode,
+  keySyms.maxKeyCode - keySyms.minKeyCode + 1,
+  modmap, serverClient);
+XkbDDXChangeControls(ki->dixdev, , );
+free(keySyms.map);
+}
+
+if (!keySyms.minKeyCode) {
 ErrorF("Couldn't load keymap from host\n");
 return BadAlloc;
 }
-ki->minScanCode = ephyrKeySyms.minKeyCode;
-ki->maxScanCode = ephyrKeySyms.maxKeyCode;
-free(ki->name);
+
+ki->minScanCode = keySyms.minKeyCode;
+ki->maxScanCode = keySyms.maxKeyCode;
+
+if (ki->name != NULL) {
+free(ki->name);
+}
+
 ki->name = strdup("Xephyr virtual keyboard");
 ephyrKbd = ki;
 return Success;
diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c
index ce9faca..cdb12b0 100644
--- a/hw/kdrive/ephyr/hostx.c
+++ b/hw/kdrive/ephyr/hostx.c
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef GLAMOR
 #include 
 #include "glamor.h"
@@ -86,8 +87,6 @@ static EphyrHostXVars HostX;
 
 static int HostXWantDamageDebug = 0;
 
-extern EphyrKeySyms ephyrKeySyms;
-
 extern Bool EphyrWantResize;
 
 char *ephyrResName = NULL;
@@ -1082,18 +1081,136 @@ hostx_paint_debug_rect(KdScreenInfo *screen,
 nanosleep(, NULL);
 }
 
-void
-hostx_load_keymap(void)
+Bool
+hostx_load_keymap(KeySymsPtr keySyms, CARD8 *modmap, XkbControlsPtr controls)
 {
 int min_keycode, max_keycode;
-
+int map_width;
+size_t i, j;
+int keymap_len;
+xcb_keysym_t *keymap;
+xcb_keycode_t *modifier_map;
+xcb_get_keyboard_mapping_cookie_t mapping_c;
+xcb_get_keyboard_mapping_reply_t *mapping_r;
+xcb_get_modifier_mapping_cookie_t modifier_c;
+xcb_get_modifier_mapping_reply_t *modifier_r;
+xcb_xkb_use_extension_cookie_t use_c;
+xcb_xkb_use_extension_reply_t *use_r;
+xcb_xkb_get_controls_cookie_t controls_c;
+xcb_xkb_get_controls_reply_t *controls_r;
+
+/* First of all, collect host X server's
+ * min_keycode and max_keycode, which are
+ * independent from XKB support. */
 min_keycode = xcb_get_setup(HostX.conn)->min_keycode;
 max_keycode = xcb_get_setup(HostX.conn)->max_keycode;
 
 EPHYR_DBG("min: %d, max: %d", min_keycode, max_keycode);
 
-ephyrKeySyms.minKeyCode = min_keycode;
-ephyrKeySyms.maxKeyCode = max_keycode;
+keySyms->minKeyCode = min_keycode;
+keySyms->maxKeyCode = max_keycode;
+
+/* Check for XKB availability in host X server */
+if (!hostx_has_extension(_xkb_id)) {
+EPHYR_LOG_ERROR("XKB extension is not supported in host X server.");
+return FALSE;
+}
+
+use_c = xcb_xkb_use_extension(HostX.conn,
+  XCB_XKB_MAJOR_VERSION,
+  XCB_XKB_MINOR_VERSION);
+use_r = xcb_xkb_use_extension_reply(HostX.conn, 

[PATCH xserver 1/2] glamor: Factor out glamor_set_color_depth from glamor_set_color

[Michel Dänzer]

From: Michel Dänzer 

The former takes explicit screen and depth parameters instead of
deriving them from a pixmap.

Signed-off-by: Michel Dänzer 
---
 glamor/glamor_transform.c | 16 
 glamor/glamor_transform.h | 12 +++-
 2 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/glamor/glamor_transform.c b/glamor/glamor_transform.c
index 17b1066..fc96fd6 100644
--- a/glamor/glamor_transform.c
+++ b/glamor/glamor_transform.c
@@ -104,20 +104,20 @@ glamor_set_destination_drawable(DrawablePtr drawable,
  */
 
 void
-glamor_set_color(PixmapPtr  pixmap,
- CARD32 pixel,
- GLint  uniform)
+glamor_set_color_depth(ScreenPtr  pScreen,
+   intdepth,
+   CARD32 pixel,
+   GLint  uniform)
 {
-glamor_screen_private *glamor_priv =
-glamor_get_screen_private((pixmap)->drawable.pScreen);
+glamor_screen_private *glamor_priv = glamor_get_screen_private(pScreen);
 float   color[4];
 
 glamor_get_rgba_from_pixel(pixel,
[0], [1], [2], [3],
-   format_for_pixmap(pixmap));
+   format_for_depth(depth));
 
-if ((pixmap->drawable.depth == 1 || pixmap->drawable.depth == 8) &&
-   glamor_priv->one_channel_format == GL_RED)
+if ((depth == 1 || depth == 8) &&
+glamor_priv->one_channel_format == GL_RED)
   color[0] = color[3];
 
 glUniform4fv(uniform, 1, color);
diff --git a/glamor/glamor_transform.h b/glamor/glamor_transform.h
index ab7b2bc..5a520eb 100644
--- a/glamor/glamor_transform.h
+++ b/glamor/glamor_transform.h
@@ -33,9 +33,19 @@ glamor_set_destination_drawable(DrawablePtr drawable,
 int *p_off_y);
 
 void
+glamor_set_color_depth(ScreenPtr  pScreen,
+   intdepth,
+   CARD32 pixel,
+   GLint  uniform);
+
+static inline void
 glamor_set_color(PixmapPtr  pixmap,
  CARD32 pixel,
- GLint  uniform);
+ GLint  uniform)
+{
+glamor_set_color_depth(pixmap->drawable.pScreen,
+   pixmap->drawable.depth, pixel, uniform);
+}
 
 Bool
 glamor_set_texture_pixmap(PixmapPtrtexture);
-- 
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 2/2] glamor: Source pictures are always depth 32

[Michel Dänzer]

From: Michel Dänzer 

We were using the destination pixmap depth to determine the source
picture format.

Fixes incorrect text rendering with some MATE desktop GTK3 themes.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94246
Signed-off-by: Michel Dänzer 
---
 glamor/glamor_program.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/glamor/glamor_program.c b/glamor/glamor_program.c
index ddab16f..0a94de6 100644
--- a/glamor/glamor_program.c
+++ b/glamor/glamor_program.c
@@ -508,9 +508,9 @@ use_source_solid(CARD8 op, PicturePtr src, PicturePtr dst, 
glamor_program *prog)
 
 glamor_set_blend(op, prog->alpha, dst);
 
-glamor_set_color(glamor_get_drawable_pixmap(dst->pDrawable),
- src->pSourcePict->solidFill.color,
- prog->fg_uniform);
+glamor_set_color_depth(dst->pDrawable->pScreen, 32,
+   src->pSourcePict->solidFill.color,
+   prog->fg_uniform);
 return TRUE;
 }
 
-- 
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