[PATCH xserver] xkb: Correct type of XkbDfltAccessXOptions.

[Matt Turner]

Declared as unsigned short in xkb/xkbAccessX.c.

Signed-off-by: Matt Turner 
---
 xkb/xkbInit.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xkb/xkbInit.c b/xkb/xkbInit.c
index 46016ab..9e45b4b 100644
--- a/xkb/xkbInit.c
+++ b/xkb/xkbInit.c
@@ -737,7 +737,7 @@ extern int XkbDfltRepeatInterval;
 extern unsigned short XkbDfltAccessXTimeout;
 extern unsigned int XkbDfltAccessXTimeoutMask;
 extern unsigned int XkbDfltAccessXFeedback;
-extern unsigned char XkbDfltAccessXOptions;
+extern unsigned short XkbDfltAccessXOptions;
 
 int
 XkbProcessArguments(int argc, char *argv[], int i)
@@ -798,7 +798,7 @@ XkbProcessArguments(int argc, char *argv[], int i)
 j++;
 }
 if (((i + 1) < argc) && (isdigit(argv[i + 1][0]))) {
-XkbDfltAccessXOptions = (unsigned char)
+XkbDfltAccessXOptions = (unsigned short)
 strtol(argv[++i], NULL, 16);
 j++;
 }
-- 
2.10.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: [xserver, 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

[Michel Dänzer]

On 23/03/17 07:59 PM, Hans de Goede wrote:
> On 20-09-16 03:58, Michel Dänzer wrote:
>> On 17/09/16 07:00 PM, Hans De Goede wrote:
>>> Commit b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma
>>> code")
>>> dropped the providing of a pScrn->ChangeGamma callback from the
>>> xf86RandR12
>>> code. Leaving pScrn->ChangeGamma NULL in most cases.
>>>
>>> This triggers the BadImplementation error in xf86ChangeGamma() :
>>>
>>> if (pScrn->ChangeGamma)
>>> return (*pScrn->ChangeGamma) (pScrn, gamma);
>>>
>>> return BadImplementation;
>>>
>>> Which causes X-apps using XF86VidModeSetGamma to crash with a
>>> X protocol error.
>>>
>>> This commit fixes this by re-introducing the xf86RandR12ChangeGamma
>>> helper removed by the commit and adjusting it to work with the new
>>> combined palette / gamma code.
>>>
>>> Fixes: b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma
>>> code")
>>
>> I suspect you really want to fix the modesetting driver to call
>> xf86HandleColormaps, so it can actually benefit from that change and
>> e.g. gamma sliders in games start working.
> 
> Ok, so going through my TODO list I started looking at this,
> amdgpu does:
> 
> if (xf86_config->num_crtc) {
> xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO,
> AMDGPU_LOGLEVEL_DEBUG,
>"Initializing kms color map\n");
> if (!miCreateDefColormap(pScreen))
> return FALSE;
> /* all amdgpus support 10 bit CLUTs */
> if (!xf86HandleColormaps(pScreen, 256, 10,
>  NULL, NULL,
>  CMAP_PALETTED_TRUECOLOR
>  | CMAP_RELOAD_ON_MODE_SWITCH))
> return FALSE;
> }
> 
> Which seems like it should mostly work for modesetting to,
> except for the all "amdgpus support 10 bit CLUTs" part,
> any ideas what to put there for modesetting, or how to
> query this from the kernel driver ?

I'm not sure either, but hardcoding 10 might be fine for modesetting as
well. The table for mapping from the post-colormap values to the final
values will be larger than necessary for hardware which only really
supports 8 bits or even less, but other than that I think the behaviour
should be mostly the same.


-- 
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: [RFC] Visual Class for On-Screen HDR Drawables

[Alex Goins]

Pinging in case this got buried.

Thanks,
Alex

On Wed, 1 Mar 2017, Alex Goins wrote:

> Thanks Adam. Inline -
> 
> On Fri, 10 Feb 2017, Adam Jackson wrote:
> 
> > On Thu, 2017-02-09 at 19:06 -0800, Alex Goins wrote:
> > > Any input?
> > 
> > Inline below...
> > 
> > > > Would it be a major problem for automatic redirection to destroy HDR?
> > > > Compositors could disable automatic redirection for DeepColor windows, 
> > > > and
> > > > redirect themselves with preserved HDR.
> > 
> > It's not a problem in the sense that the actual HDR window content
> > would still exist somewhere; we just need to be able to do _something_
> > when an HDR window ends up in Automatic redirection. We could skip
> > painting it to the parent, we could clamp to some range...
> 
> Right, as long as it's acceptable for it to be done on a best-effort basis I
> think that makes sense, and if we can get away with skipping painting it
> altogether in the worst case that gives us some flexibility to add new formats
> later without breaking compatibility with older versions.
> 
> > > > One of the reasons why we initially went with the idea of a visual 
> > > > opaque to
> > > > core/Render operations is that there are other HDR encodings that have 
> > > > different
> > > > transfer functions from the HDR format to sRGB. It sounds like the 
> > > > current train
> > > > of thought with clamping to the sRGB range assumes that we are 
> > > > operating only on
> > > > the linear FP16 encoding of scRGB, which is highly limiting. scRGB is 
> > > > useful if
> > > > we are trying to composite HDR and SDR content together, but there are 
> > > > other
> > > > formats as well. Even the scRGB color space has support for a 12-bit 
> > > > nonlinear
> > > > encoding in addition to the 16-bit linear one. Android and Windows both 
> > > > have
> > > > support for multiple HDR formats.
> > 
> > Sure. Picking sRGB here is just a plausible default. What we're
> > trying to cover by exposing HDR content through existing visual classes
> > and imaging ops is just "do something reasonable for compatibility with
> > non-HDR-aware apps". If there's some other transformation to unorm8
> > that would produce better visual results along those paths then great,
> > we just need to figure out how to expose that to a) application control
> > b) compositor visibility. There are options there, it could vary by
> > visual (although I think that's not how GLX visuals want to work), it
> > could be some new bit of per-window state that we add to Fixes or XC-
> > MISC or a new extension, it could be a new NETWM property...
> 
> I don't have much of an opinion on whether we should define a whole new
> extension or extend an existing one, although from reading the description of
> the XFIXES extension it doesn't seem like the right scope, in that we aren't
> trying to eliminate a problem caused by a workaround. I hadn't considered 
> NETWM,
> that could make sense to put pressure on window managers to composite HDR
> content correctly rather than relying on automatic redirection, even if most 
> of
> the info is queryable through an extension.
> 
> More on this topic below.
> 
> > > > One concern that came up internally is handling pixmaps, which specify 
> > > > a depth
> > > > but not a Visual. I looked a bit into Mutter and Compton, and they seem 
> > > > to deal
> > > > with this by querying visual properties from the root window, and 
> > > > assuming there
> > > > aren't any pixmap-specific parameters that would affect the texture 
> > > > target.
> > > > However, since the Pixmap is queried from the Window, they should be 
> > > > able to get
> > > > the parameters from the Visual of the Window backing the Pixmap.
> > 
> > I feel comfortable saying these compositors are wrong and should be
> > using glXQueryDrawable to figure out the fbconfig for the window-
> > pixmap; though, having said that, I'm not sure Xorg's glx would return
> > something sensible.
> > 
> > But again, I think the colorspace is more properly a property of the
> > drawable than of the fbconfig. The EGL HDR specs seem to be written in
> > terms of per-drawable state rather than new configs. So we might need
> > to add a new attribute for QueryDrawable; that's fine, the set of
> > people involved in new GLX extension specs are all already on this
> > list, if not this thread.
> 
> FYI - it's only the texture_from_pixmap texture target attributes that they 
> base
> off of the root window, e.g. GLX_TEXTURE_2D_EXT, GLX_TEXTURE_RECTANGLE_EXT,
> GLX_TEXTURE_FORMAT_RBGA_EXT. They get the fbconfig from the X pixmap's depth,
> along with a few other static attributes, which is still a problem for us 
> since
> with HDR we'll need more info than just depth. The texture target derivation 
> is
> still wrong behavior, however, as it should be done using FBConfig attributes.
> If they want to avoid looking up FBconfig attributes every time a window is
> mapped, a better implementation suggested 

[PATCH xrandr] Adding a "--filter" flag

[Pablo De La Garza]

From: pdelagarza 

Flag can be set to "nearest" or "bilinear"

Signed-off-by: Pablo De La Garza 
---
 xrandr.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/xrandr.c b/xrandr.c
index dcfdde0..c2cc82e 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -54,6 +54,12 @@ static Bool  automatic = False;
 static Boolproperties = False;
 static Boolgrab_server = True;
 static Boolno_primary = False;
+static int  filterType = -1;
+
+static const char *filterTypeList[2] = {
+"bilinear",
+"nearest"};
+
 
 static const char *direction[5] = {
 "normal", 
@@ -118,6 +124,7 @@ usage(void)
"  --fb x\n"
"  --fbmm x\n"
"  --dpi /\n"
+   "  --filter ,filterType: nearest, bilinear\n"
"  --output \n"
"  --auto\n"
"  --mode \n"
@@ -285,6 +292,7 @@ typedef enum _changes {
 changes_panning = (1 << 10),
 changes_gamma = (1 << 11),
 changes_primary = (1 << 12),
+changes_filter = (1 << 13),
 } changes_t;
 
 typedef enum _name_kind {
@@ -1311,6 +1319,11 @@ set_output_info (output_t *output, RROutput xid, 
XRROutputInfo *output_info)
output->transform.params = NULL;
}
 }
+if (output->changes & changes_filter)
+{
+output->transform.filter = filterTypeList[filterType];
+}
+
 
 /* set primary */
 if (!(output->changes & changes_primary))
@@ -2808,6 +2821,28 @@ main (int argc, char **argv)
action_requested = True;
continue;
}
+
+if (!strcmp("--filter", argv[i]))
+{
+if (!config_output) argerr ("%s must be used after --output\n", 
argv[i]);
+if (++i >= argc) argerr("%s requires an argument\n", argv[i-1]);
+
+for (int t=0;t < 
sizeof(filterTypeList)/sizeof(filterTypeList[0]);t++)
+{
+if (!strcmp(filterTypeList[t],argv[i]))
+{
+filterType = t;
+break;
+}
+}
+
+if (filterType==-1) argerr("Bad argument: %s, for a filter\n", 
argv[i]);
+
+config_output->changes |= changes_filter;
+action_requested = True;
+continue;
+}
+
if (!strcmp ("--crtc", argv[i])) {
if (!config_output) argerr ("%s must be used after --output\n", 
argv[i]);
if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
-- 
2.7.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

Re: [PATCH 0/2] RFC: Introduce keyboard grabbing and shortcuts inhibitor protocols

[Bill Spitzak]

On Thu, Mar 23, 2017 at 11:04 AM, Bill Spitzak  wrote:
> On Thu, Mar 23, 2017 at 12:35 AM, Olivier Fourdan  wrote:
>>
>> Hi,
>>
>>> I can't imagine blocking all/none shortcuts can be the only choices.
>>> What if the nested wm does not use one of the shortcuts? And whether a
>>> particular shortcut is used can vary: a tab between windows may not
>>> work if you are on the last window, in that case it would be nice if
>>> tab then went out of the nested wm and to the next main window.
>>>
>>> An "I consumed/ignored this event" request sent back from clients to
>>> the compositor would allow this to work. This also matches how a
>>> number of toolkits work so it would make integration of them into
>>> desktops better.
>>
>> I'd rather keep the protocol lean and simple.
>>
>> If anything, existing application do not need to know which shortcuts are 
>> used, for example, virt-viewer has no idea what particular shortcuts the 
>> desktop running on the guest OS is using.
>
> Of course the clients don't know what shortcuts the wm is using. I
> never intended to imply that.
>
> The client knows what shortcuts the CLIENT uses. The reason for this
> api is so this information can be communicated to the wm. The client
> can say it ignored a keystroke without knowing whether or not the wm
> will use it.
>
>> And toolkits do not know that either.
>
> Qt and GTK and FLTK all have a "the widget consumed this event"
> indicator that is set or returned after an event is passed to a
> widget. I would suspect this is true of all other modern toolkits. A
> way to propagate this information back to the wm would make it easy to
> cleanly interface such toolkits with the wm.
>
>>> As for the X thing, I don't see why any new api is necessary. The X
>>> emulator can just set normal Wayland keyboard focus to the window and
>>> do whatever is necessary so that moving the focus away is discouraged
>>> and it is easy to get the focus back (ie mouse enter and click try to
>>> put it back), rather than add an extremely dangerous and unwanted api
>>> from X to Wayland.
>>
>> It is necessary for [1] and [2], ie X11 applications that map an override 
>> redirect window and grab the keyboard. I tried the appoach you mention and 
>> was denied, on valid the grounds [3] that O-R should not be focused by the 
>> WM.
>>
>> While this works just fine in X11 thanks to the keyboard grab, it cannot 
>> work in Xwayland without a mechanism that route the keyboard events to the 
>> surface even when not focused.
>>
>> Cheers,
>> Olivier
>>
>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=96547
>> [2] https://bugzilla.gnome.org/show_bug.cgi?id=752956
>> [3] https://bugzilla.gnome.org/show_bug.cgi?id=752956#c4
>
> Sorry I'm looking at bug #3 and I do not see anything in the comments
> that says you need to emulate keyboard grab exactly. They are saying
> that *something* needs to be done (ie the current X on wayland is not
> sending any keystrokes to override-redirect windows) but they
> certainly are not saying precise emulation is needed. It seems to me
> that doing a request for keyboard focus (in Wayland) is all that is
> needed. It may also need the easy ability to put the focus back with a
> click or mouse enter even if the client does not actively do that.

More specifically, assume XSetInputFocus() works. Exactly what it does
depends on the Wayland server but I think we can assume that it will
somehow allow the user's keystrokes to be sent to that window. In the
worst case the user may need to activate or raise the window, or
choose it from the "attention needed" panel.

Keyboard grab can be emulated on Wayland by having the creation of the
keyboard grab do XSetInputFocus(), and as long as the keyboard grab
exists, doing XSetInputFocus() on various events such as mouse clicks
(to deal with X clients that think they cannot lose the keyboard
grab). I believe dropping the keyboard grab does not have to do
anything (ie the keystrokes will continue to go to the window).
___
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 0/2] RFC: Introduce keyboard grabbing and shortcuts inhibitor protocols

[Bill Spitzak]

On Thu, Mar 23, 2017 at 12:35 AM, Olivier Fourdan  wrote:
>
> Hi,
>
>> I can't imagine blocking all/none shortcuts can be the only choices.
>> What if the nested wm does not use one of the shortcuts? And whether a
>> particular shortcut is used can vary: a tab between windows may not
>> work if you are on the last window, in that case it would be nice if
>> tab then went out of the nested wm and to the next main window.
>>
>> An "I consumed/ignored this event" request sent back from clients to
>> the compositor would allow this to work. This also matches how a
>> number of toolkits work so it would make integration of them into
>> desktops better.
>
> I'd rather keep the protocol lean and simple.
>
> If anything, existing application do not need to know which shortcuts are 
> used, for example, virt-viewer has no idea what particular shortcuts the 
> desktop running on the guest OS is using.

Of course the clients don't know what shortcuts the wm is using. I
never intended to imply that.

The client knows what shortcuts the CLIENT uses. The reason for this
api is so this information can be communicated to the wm. The client
can say it ignored a keystroke without knowing whether or not the wm
will use it.

> And toolkits do not know that either.

Qt and GTK and FLTK all have a "the widget consumed this event"
indicator that is set or returned after an event is passed to a
widget. I would suspect this is true of all other modern toolkits. A
way to propagate this information back to the wm would make it easy to
cleanly interface such toolkits with the wm.

>> As for the X thing, I don't see why any new api is necessary. The X
>> emulator can just set normal Wayland keyboard focus to the window and
>> do whatever is necessary so that moving the focus away is discouraged
>> and it is easy to get the focus back (ie mouse enter and click try to
>> put it back), rather than add an extremely dangerous and unwanted api
>> from X to Wayland.
>
> It is necessary for [1] and [2], ie X11 applications that map an override 
> redirect window and grab the keyboard. I tried the appoach you mention and 
> was denied, on valid the grounds [3] that O-R should not be focused by the WM.
>
> While this works just fine in X11 thanks to the keyboard grab, it cannot work 
> in Xwayland without a mechanism that route the keyboard events to the surface 
> even when not focused.
>
> Cheers,
> Olivier
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=96547
> [2] https://bugzilla.gnome.org/show_bug.cgi?id=752956
> [3] https://bugzilla.gnome.org/show_bug.cgi?id=752956#c4

Sorry I'm looking at bug #3 and I do not see anything in the comments
that says you need to emulate keyboard grab exactly. They are saying
that *something* needs to be done (ie the current X on wayland is not
sending any keystrokes to override-redirect windows) but they
certainly are not saying precise emulation is needed. It seems to me
that doing a request for keyboard focus (in Wayland) is all that is
needed. It may also need the easy ability to put the focus back with a
click or mouse enter even if the client does not actively do that.
___
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: Honor xorg.conf for 16bpp

[Adam Jackson]

On Thu, 2017-03-23 at 11:20 +0200, Alkis Georgopoulos wrote:
> On 23/03/2017 11:00 πμ, Timo Aaltonen wrote:
> > 'xinit -- -depth 16' still doesn't work, but xorg.conf does.
> > 
> 
> I verify this on kvm/cirrus/modeset and on vbox/vboxvideo/modeset.
> It also fixes the crash on Intel broadwell with modesetting!
> 
> But without a xorg.conf, i.e. with `xinit -- -depth 16`, everything is 
> still broken.

Ugh, yeah. The issue there is the command line options aren't directly
visible to the drivers. I'll see if I can work something out.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 6/7] xserver: Unifdef HAVE_CONFIG_H

[Adam Jackson]

On Thu, 2017-03-23 at 10:11 +1000, Peter Hutterer wrote:
> unifdef apparently isn't smart enough to realise that it leaves us with an
> empty else branch now.
> 
> You're missing a few s-o-b as well in the commit messages, but with all that
> fixed, Reviewed-by: Peter Hutterer 

Fixed and pushed:

remote: I: patch #145811 updated using rev 
1b1a8c481773e15142202a7b761d614b33f12577.
remote: I: patch #145809 updated using rev 
5c7ed785e3bdb9f0fbf8fbfdc93b5fdd2b2c7dbf.
remote: I: patch #145810 updated using rev 
190c2adf4a237a4c0dc13d7566ca91662271d3e4.
remote: I: patch #145808 updated using rev 
2da405759fbabd4b918838a0de728c1911b4a2fa.
remote: I: patch #145812 updated using rev 
266af991c8e41e62f054ac9870468a9ba2aaa9f2.
remote: E: failed to find patch for rev 
e2e50c509718ea8c7f4684dc18f5ce66e526792b.
remote: I: 5 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   ad6689b..e2e50c5  master -> master

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver] xf86: dri2: Use va_gl as vdpau_driver for Intel i965 GPUs

[Hans de Goede]

The modesetting driver (which now often is used with Intel GPUs),
relies on dri2_probe_driver_name() to get the dri and vdpau driver
names, before this commit it would always assign the same name to
the 2 names. But the vdpau driver for i965 GPUs should be va_gl
(i915 does not support vdpau at all).

This commit modifies the used lookup table and dri2_probe_driver_name()
to set the vdpau_driver to va_gl for i965 GPUs, it leaves the 2
names the same for all other GPUs.

Note this commit adds a FIXME comment for a memory leak in
dri2_probe_driver_name(), that leak was already present and fixing
it falls outside of the scope of this commit.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1413733
Cc: kwiz...@gmail.com
Signed-off-by: Hans de Goede 
---
 hw/xfree86/dri2/dri2.c  | 31 +++--
 hw/xfree86/dri2/pci_ids/pci_id_driver_map.h | 21 +--
 2 files changed, 31 insertions(+), 21 deletions(-)

diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index f9f9859..5315338 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -1437,14 +1437,18 @@ get_prime_id(void)
 
 #include "pci_ids/pci_id_driver_map.h"
 
-static char *
-dri2_probe_driver_name(ScreenPtr pScreen, DRI2InfoPtr info)
+static void
+dri2_probe_driver_name(ScreenPtr pScreen, DRI2InfoPtr info,
+   const char **dri_driver_ret,
+   const char **vdpau_driver_ret)
 {
 #ifdef WITH_LIBDRM
 int i, j;
-char *driver = NULL;
 drmDevicePtr dev;
 
+*dri_driver_ret = NULL;
+*vdpau_driver_ret = NULL;
+
 /* For non-PCI devices and drmGetDevice fail, just assume that
  * the 3D driver is named the same as the kernel driver. This is
  * currently true for vc4 and msm (freedreno).
@@ -1456,12 +1460,14 @@ dri2_probe_driver_name(ScreenPtr pScreen, DRI2InfoPtr 
info)
 xf86DrvMsg(pScreen->myNum, X_ERROR,
"[DRI2] Couldn't drmGetVersion() on non-PCI device, "
"no driver name found.\n");
-return NULL;
+return;
 }
 
-driver = strndup(version->name, version->name_len);
+/* FIXME this gets leaked */
+*dri_driver_ret = strndup(version->name, version->name_len);
+*vdpau_driver_ret = *dri_driver_ret;
 drmFreeVersion(version);
-return driver;
+return;
 }
 
 for (i = 0; driver_map[i].driver; i++) {
@@ -1469,13 +1475,15 @@ dri2_probe_driver_name(ScreenPtr pScreen, DRI2InfoPtr 
info)
 continue;
 
 if (driver_map[i].num_chips_ids == -1) {
- driver = strdup(driver_map[i].driver);
+ *dri_driver_ret = driver_map[i].driver;
+ *vdpau_driver_ret = driver_map[i].vdpau_driver;
  goto out;
 }
 
 for (j = 0; j < driver_map[i].num_chips_ids; j++) {
 if (driver_map[i].chip_ids[j] == dev->deviceinfo.pci->device_id) {
-driver = strdup(driver_map[i].driver);
+*dri_driver_ret = driver_map[i].driver;
+*vdpau_driver_ret = driver_map[i].vdpau_driver;
 goto out;
 }
 }
@@ -1487,9 +1495,9 @@ dri2_probe_driver_name(ScreenPtr pScreen, DRI2InfoPtr 
info)
dev->deviceinfo.pci->vendor_id, dev->deviceinfo.pci->device_id);
 out:
 drmFreeDevice();
-return driver;
 #else
-return NULL;
+*dri_driver_ret = NULL;
+*vdpau_driver_ret = NULL;
 #endif
 }
 
@@ -1611,7 +1619,8 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
 if (info->driverName) {
 ds->driverNames[0] = info->driverName;
 } else {
-ds->driverNames[0] = ds->driverNames[1] = 
dri2_probe_driver_name(pScreen, info);
+dri2_probe_driver_name(pScreen, info,
+   >driverNames[0], >driverNames[1]);
 if (!ds->driverNames[0])
 return FALSE;
 }
diff --git a/hw/xfree86/dri2/pci_ids/pci_id_driver_map.h 
b/hw/xfree86/dri2/pci_ids/pci_id_driver_map.h
index da7ea1c..7036d10 100644
--- a/hw/xfree86/dri2/pci_ids/pci_id_driver_map.h
+++ b/hw/xfree86/dri2/pci_ids/pci_id_driver_map.h
@@ -66,21 +66,22 @@ static const int vmwgfx_chip_ids[] = {
 static const struct {
int vendor_id;
const char *driver;
+   const char *vdpau_driver;
const int *chip_ids;
int num_chips_ids;
 } driver_map[] = {
-   { 0x8086, "i915", i915_chip_ids, ARRAY_SIZE(i915_chip_ids) },
-   { 0x8086, "i965", i965_chip_ids, ARRAY_SIZE(i965_chip_ids) },
+   { 0x8086, "i915", "i915", i915_chip_ids, ARRAY_SIZE(i915_chip_ids) },
+   { 0x8086, "i965", "va_gl", i965_chip_ids, ARRAY_SIZE(i965_chip_ids) },
 #ifndef DRIVER_MAP_GALLIUM_ONLY
-   { 0x1002, "radeon", r100_chip_ids, ARRAY_SIZE(r100_chip_ids) },
-   { 0x1002, "r200", r200_chip_ids, ARRAY_SIZE(r200_chip_ids) },
+   { 0x1002, "radeon", "radeon", r100_chip_ids, ARRAY_SIZE(r100_chip_ids) },
+ 

Re: [xserver, 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

[Hans de Goede]

Hi,

On 20-09-16 03:58, Michel Dänzer wrote:

On 17/09/16 07:00 PM, Hans De Goede wrote:

Commit b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
dropped the providing of a pScrn->ChangeGamma callback from the xf86RandR12
code. Leaving pScrn->ChangeGamma NULL in most cases.

This triggers the BadImplementation error in xf86ChangeGamma() :

if (pScrn->ChangeGamma)
return (*pScrn->ChangeGamma) (pScrn, gamma);

return BadImplementation;

Which causes X-apps using XF86VidModeSetGamma to crash with a
X protocol error.

This commit fixes this by re-introducing the xf86RandR12ChangeGamma
helper removed by the commit and adjusting it to work with the new
combined palette / gamma code.

Fixes: b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")


I suspect you really want to fix the modesetting driver to call
xf86HandleColormaps, so it can actually benefit from that change and
e.g. gamma sliders in games start working.


Ok, so going through my TODO list I started looking at this,
amdgpu does:

if (xf86_config->num_crtc) {
xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, AMDGPU_LOGLEVEL_DEBUG,
   "Initializing kms color map\n");
if (!miCreateDefColormap(pScreen))
return FALSE;
/* all amdgpus support 10 bit CLUTs */
if (!xf86HandleColormaps(pScreen, 256, 10,
 NULL, NULL,
 CMAP_PALETTED_TRUECOLOR
 | CMAP_RELOAD_ON_MODE_SWITCH))
return FALSE;
}

Which seems like it should mostly work for modesetting to,
except for the all "amdgpus support 10 bit CLUTs" part,
any ideas what to put there for modesetting, or how to
query this from the kernel driver ?

Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] configure.ac: fix checking for libdrm version after 9232835bd

[Michel Dänzer]

On 17/03/17 07:20 PM, Mariusz Bialonczyk wrote:
> Fix commit 9232835bd16b6948442f7a4588fb9376782cb814
> glamor: use drmGetDeviceNameFromFD2 when available
> 
> No matter what libdrm version was installed, it always set
> the GLAMOR_HAS_DRM_NAME_FROM_FD_2 conditional to 1.
> This obviously leads to compilation problems.
> 
> Signed-off-by: Mariusz Bialonczyk 
> Cc: Qiang Yu 
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index ac11e6572..0f2f68abb 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2167,7 +2167,7 @@ if test "x$GLAMOR" = xyes; then
>   fi
>   fi
>  
> - PKG_CHECK_MODULES(LIBDRM, "libdrm >= 2.4.74",
> + PKG_CHECK_EXISTS(libdrm >= 2.4.74,
>   [AC_DEFINE(GLAMOR_HAS_DRM_NAME_FROM_FD_2, 1, [Have 
> GLAMOR_HAS_DRM_NAME_FROM_FD_2])], [])
>  fi
>  AM_CONDITIONAL([GLAMOR_EGL], [test "x$GBM" = xyes])
> 

Pushed with slightly tweaked formatting and commit log, thanks!

   eb2cf1172..ad6689b7d  master -> master


-- 
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 xserver] modesetting: Honor xorg.conf for 16bpp

[Alkis Georgopoulos]

On 23/03/2017 11:00 πμ, Timo Aaltonen wrote:

'xinit -- -depth 16' still doesn't work, but xorg.conf does.



I verify this on kvm/cirrus/modeset and on vbox/vboxvideo/modeset.
It also fixes the crash on Intel broadwell with modesetting!

But without a xorg.conf, i.e. with `xinit -- -depth 16`, everything is 
still broken.

___
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: Honor xorg.conf for 16bpp

[Timo Aaltonen]

On 21.03.2017 21:57, Adam Jackson wrote:
> The 32->24 support patch messed this up.
> 
> Bugzilla: https://bugs.freedesktop.org/100246
> Bugzilla: https://bugs.freedesktop.org/100295
> Signed-off-by: Adam Jackson 

'xinit -- -depth 16' still doesn't work, but xorg.conf does.


-- 
t
___
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 0/2] RFC: Introduce keyboard grabbing and shortcuts inhibitor protocols

[Olivier Fourdan]

Hi,

> I can't imagine blocking all/none shortcuts can be the only choices.
> What if the nested wm does not use one of the shortcuts? And whether a
> particular shortcut is used can vary: a tab between windows may not
> work if you are on the last window, in that case it would be nice if
> tab then went out of the nested wm and to the next main window.
> 
> An "I consumed/ignored this event" request sent back from clients to
> the compositor would allow this to work. This also matches how a
> number of toolkits work so it would make integration of them into
> desktops better.

I'd rather keep the protocol lean and simple.

If anything, existing application do not need to know which shortcuts are used, 
for example, virt-viewer has no idea what particular shortcuts the desktop 
running on the guest OS is using.

And toolkits do not know that either.

> As for the X thing, I don't see why any new api is necessary. The X
> emulator can just set normal Wayland keyboard focus to the window and
> do whatever is necessary so that moving the focus away is discouraged
> and it is easy to get the focus back (ie mouse enter and click try to
> put it back), rather than add an extremely dangerous and unwanted api
> from X to Wayland.

It is necessary for [1] and [2], ie X11 applications that map an override 
redirect window and grab the keyboard. I tried the appoach you mention and was 
denied, on valid the grounds [3] that O-R should not be focused by the WM.

While this works just fine in X11 thanks to the keyboard grab, it cannot work 
in Xwayland without a mechanism that route the keyboard events to the surface 
even when not focused.

Cheers,
Olivier

[1] https://bugs.freedesktop.org/show_bug.cgi?id=96547
[2] https://bugzilla.gnome.org/show_bug.cgi?id=752956
[3] https://bugzilla.gnome.org/show_bug.cgi?id=752956#c4
___
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 0/7] meson prep work

[Daniel Stone]

On Wed, 22 Mar 2017 at 10:11 pm, Eric Anholt  wrote:

> As I've mentioned in IRC, I'm in the process of converting the X
> Server to Meson.  It's proved to be a delight to work with, with a
> helpful IRC community for when you get stuck.  The build system will
> probably be half the size when meson is done, and I'm doing full
> rebuilds in a tiny fraction of the time it takes to ./configure.
>
> In the process, I've run into some silly stuff in our tree that could
> be cleaned up independently of whether we go with meson.
>

Woo! For the series, modulo 7/7:
Reviewed-by: Daniel Stone 

I've had really positive results doing it for Wayland/Weston too. Meson
isn't perfect, but ultimately everything I felt was a shortcoming in the
build system got a short-term workaround provided, and a better fix
long-term. And I didn't once have to remember how M4 quoting worked.

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