RE: [Glamor] glamor with xserver > 1.12
> -Original Message- > From: > glamor-bounces+zhigang.gong=linux.intel@lists.freedesktop.org > [mailto:glamor-bounces+zhigang.gong=linux.intel.com@lists.freedesktop.o > rg] On Behalf Of Chris Wilson > Sent: Tuesday, March 12, 2013 7:05 PM > To: Michel Dänzer > Cc: Alex B; xorg-devel@lists.x.org; gla...@lists.freedesktop.org > Subject: Re: [Glamor] glamor with xserver > 1.12 > > On Mon, Mar 11, 2013 at 07:23:52PM +0100, Michel Dänzer wrote: > > On Mon, 2013-03-11 at 00:25 +0400, Alex B wrote: > > > > > > I need working glamor to get 3d acceleration on my video card > > > (Radeon HD 7700) My current distribution Arch Linux provides > xserver > > > 1.13 and about to move on 1.14. > > > > > > Only way I found to make glamor work is to add /usr/lib/xorg/modules > > > to ld.so.conf. > > > > > > So question is: > > > Is it valid way to make glamor work and can be recommended for > distro packaging? > > > > I think it would be better to install libglamor.so in the normal lib > > directory. Can you submit a glamor patch or bug report for that? > > > > > > But, this is rather interesting news: So far the assumption has been > > that glamor cannot work at all with current xserver. However, I cannot > > reproduce the problem I reported a while ago even with xserver 1.13.0, > > let alone newer versions, though I still can with the pre-1.13 Git > > snapshot I reported the problem for. Apparently the problem was fixed > > before the final 1.13.0 release. Was I really the only one who ever > > tried this, and everyone else just took my word for it? :\ > > libglamor is still very confused and calls into the wrong GL functions for me > with intel and Xorg-1.14. [Gong, Zhigang] Unfortunately, that's expected behavior of current glamor on intel platform (with mesa and latest xorg server). Junyan submitted some patchset to this lsits to fix this issue, but the work is incomplete. And if someone have time and interests to fix it, those patchset may be a good reference. The major gap is to create a GL context in xserver side. We depends on the xorg module initialization to make sure we can get a correct GL context for glamor. But latest xorg change the module initialization method, and break us. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > ___ > Glamor mailing list > gla...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/glamor ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Glamor] glamor with xserver > 1.12
On Mon, 2013-03-18 at 16:40 +0800, Zhigang Gong wrote: > > -Original Message- > > From: > > glamor-bounces+zhigang.gong=linux.intel@lists.freedesktop.org > > [mailto:glamor-bounces+zhigang.gong=linux.intel.com@lists.freedesktop.o > > rg] On Behalf Of Chris Wilson > > Sent: Tuesday, March 12, 2013 7:05 PM > > To: Michel Dänzer > > Cc: Alex B; xorg-devel@lists.x.org; gla...@lists.freedesktop.org > > Subject: Re: [Glamor] glamor with xserver > 1.12 > > > > On Mon, Mar 11, 2013 at 07:23:52PM +0100, Michel Dänzer wrote: > > > On Mon, 2013-03-11 at 00:25 +0400, Alex B wrote: > > > > > > > > I need working glamor to get 3d acceleration on my video card > > > > (Radeon HD 7700) My current distribution Arch Linux provides > > xserver > > > > 1.13 and about to move on 1.14. > > > > > > > > Only way I found to make glamor work is to add /usr/lib/xorg/modules > > > > to ld.so.conf. > > > > > > > > So question is: > > > > Is it valid way to make glamor work and can be recommended for > > distro packaging? > > > > > > I think it would be better to install libglamor.so in the normal lib > > > directory. Can you submit a glamor patch or bug report for that? > > > > > > > > > But, this is rather interesting news: So far the assumption has been > > > that glamor cannot work at all with current xserver. However, I cannot > > > reproduce the problem I reported a while ago even with xserver 1.13.0, > > > let alone newer versions, though I still can with the pre-1.13 Git > > > snapshot I reported the problem for. Apparently the problem was fixed > > > before the final 1.13.0 release. Was I really the only one who ever > > > tried this, and everyone else just took my word for it? :\ > > > > libglamor is still very confused and calls into the wrong GL functions for > me > > with intel and Xorg-1.14. > [Gong, Zhigang] > Unfortunately, that's expected behavior of current glamor on intel platform > (with mesa and latest xorg server). > Junyan submitted some patchset to this lsits to fix this issue, but the work > is incomplete. And if someone have > time and interests to fix it, those patchset may be a good reference. The > major gap is to create a GL context in > xserver side. We depends on the xorg module initialization to make sure we > can get a correct GL context for > glamor. But latest xorg change the module initialization method, and break > us. It turns out that problem introduced during the 1.13 cycle was fixed somehow before the final 1.13 release. Chris got it working with 1.14, he hadn't been loading the glamoregl module early. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Glamor] glamor with xserver > 1.12
Oh, Really? That's a great news for me, I will have a try tomorrow. But To be honest, even it works, such dependencies is still an issue. And I'm afraid it may break the indirect GLX's context somehow. As the GLX server side may have a different gl dispatch table from the mesa's. On Mon, Mar 18, 2013 at 4:48 PM, Michel Dänzer wrote: > On Mon, 2013-03-18 at 16:40 +0800, Zhigang Gong wrote: > > > -Original Message- > > > From: > > > glamor-bounces+zhigang.gong=linux.intel@lists.freedesktop.org > > > [mailto:glamor-bounces+zhigang.gong > =linux.intel.com@lists.freedesktop.o > > > rg] On Behalf Of Chris Wilson > > > Sent: Tuesday, March 12, 2013 7:05 PM > > > To: Michel Dänzer > > > Cc: Alex B; xorg-devel@lists.x.org; gla...@lists.freedesktop.org > > > Subject: Re: [Glamor] glamor with xserver > 1.12 > > > > > > On Mon, Mar 11, 2013 at 07:23:52PM +0100, Michel Dänzer wrote: > > > > On Mon, 2013-03-11 at 00:25 +0400, Alex B wrote: > > > > > > > > > > I need working glamor to get 3d acceleration on my video card > > > > > (Radeon HD 7700) My current distribution Arch Linux provides > > > xserver > > > > > 1.13 and about to move on 1.14. > > > > > > > > > > Only way I found to make glamor work is to add > /usr/lib/xorg/modules > > > > > to ld.so.conf. > > > > > > > > > > So question is: > > > > > Is it valid way to make glamor work and can be recommended for > > > distro packaging? > > > > > > > > I think it would be better to install libglamor.so in the normal lib > > > > directory. Can you submit a glamor patch or bug report for that? > > > > > > > > > > > > But, this is rather interesting news: So far the assumption has been > > > > that glamor cannot work at all with current xserver. However, I > cannot > > > > reproduce the problem I reported a while ago even with xserver > 1.13.0, > > > > let alone newer versions, though I still can with the pre-1.13 Git > > > > snapshot I reported the problem for. Apparently the problem was fixed > > > > before the final 1.13.0 release. Was I really the only one who ever > > > > tried this, and everyone else just took my word for it? :\ > > > > > > libglamor is still very confused and calls into the wrong GL functions > for > > me > > > with intel and Xorg-1.14. > > [Gong, Zhigang] > > Unfortunately, that's expected behavior of current glamor on intel > platform > > (with mesa and latest xorg server). > > Junyan submitted some patchset to this lsits to fix this issue, but the > work > > is incomplete. And if someone have > > time and interests to fix it, those patchset may be a good reference. The > > major gap is to create a GL context in > > xserver side. We depends on the xorg module initialization to make sure > we > > can get a correct GL context for > > glamor. But latest xorg change the module initialization method, and > break > > us. > > It turns out that problem introduced during the 1.13 cycle was fixed > somehow before the final 1.13 release. Chris got it working with 1.14, > he hadn't been loading the glamoregl module early. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Debian, X and DRI developer > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] [xorg-dev][xserver] Full support of sRGB capable fbconfigs.
Tomasz Lis writes: > Changes to correctly initialize the sRGB capability attribute and > transfer it between XServer and the client. Modifications include > extension string, transferring visual config attribs and fbconfig > attribs. Also, attribute is initialized in the modules which do not > really use it (xquartz and xwin). > This version advertises both ARB and EXT strings, and initializes > the capability to default value of FALSE. It has corrected required > GLX version and does not influence swrast. The sRGB capable attribute > is attached only to those configs which do have this capability. > Both ARB and EXT versions share the same GLX extension enabling bit. Merged. 5047810..cf89aa5 master -> master -- keith.pack...@intel.com pgpNYiD4f0uc1.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] -next for 1.15
Peter Hutterer writes: > Alan Coopersmith (8): > Handle failure to create counter in init_system_idle_counter > Stop leaking overlayWin in PanoramiXCompositeGetOverlayWindow error > paths > Free keymap on error in Xephyr's hostx_load_keymap > Make xf86ValidateModes actually copy clock range list to screen pointer > Avoid NULL pointer dereference in xf86TokenToOptinfo if token not found > Avoid memory leak on realloc failure in localRegisterFreeBoxCallback > xf86XvMCScreenInit: Avoid leak if dixRegisterPrivateKey fails > Avoid memory leak in ddc resort() if find_header() fails > > Andreas Wettstein (1): > xkb: Fixes to LatchMods/LatchGroup > > Daniel Martin (2): > ephyr: Add -resizeable option > ephyr: Fix crash on 24bpp host framebuffer > > Marcin Slusarz (1): > os: use libunwind to generate backtraces > > Peter Harris (1): > xkb: Set nIndicators in XkbGetIndicatorMap > > Peter Hutterer (13): > randr: fix "set but unused" warnings > xfree86: drop unused prevSIGIO > fb: drop two unneeded shadowing variables > Xext: renaming shadowing variable > Xext: rename two shadowing variables > xkb: remove unused variable 'names' > xfree86: remove redundant declaration of inputInfo > Merge branch 'master' of > git+ssh://people.freedesktop.org/~alanc/xserver into next > dix: FreeAllAtoms() on reset > dix: only show the cursor if a window defines one (#58398) > os: document pnprintf as sigsafe snprintf > kdrive: fix "set but not used" warnings > xephyr: fix "set but not used warnings" Merged. cf89aa5..116f020 master -> master -- keith.pack...@intel.com pgpwKd5VWBH0Y.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] GLX/DRI2: Do not expose INTEL_swap_event without swap control
Zack Rusin writes: > Swap events depent on the implementation of ScheduleSwap. By > unconditionally enabling GLX_INTEL_swap_event we're breaking > the system with drivers that don't support it because the apps > are forever stuck waiting for an event that will never be > delivered. So lets enable the extension only if the hooks it > depends on are actually there. Merged. 116f020..190b032 master -> master -- keith.pack...@intel.com pgpHHXGdcMmJJ.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] GLX/DRI2: Do not expose INTEL_swap_event without swap control
Ian Romanick writes: > Reviewed-by: Ian Romanick > Cc: Keith Packard > > The last one is important... without it, Keith will never notice your > patch. :) I've adjusted my mail filters so I can monitor patches even without having my name on them. Let me know if I miss stuff though! -- keith.pack...@intel.com pgpVWTP0mY3gv.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] compiler fix for 1.14, misc other
Peter Hutterer writes: > Peter Hutterer (1): > xfixes: ifdef PanoramiXFixes* (#62015) > > Robert Morell (2): > configure.ac: Require inputproto 2.3 > list.h: Make xorg_list_init inline Merged. 190b032..c2ede8f master -> master -- keith.pack...@intel.com pgpupG7UfSrhV.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xf86: return NULL for xf86CompatOutput if config->compat_output is -1
Aaron Plattner writes: > If there is no compat output, config->compat_output is -1 and xf86CompatOutput > reads before the beginning of the outputs array. Did you happen to review users of this function and make sure they all handle NULL return values? The other 'obvious' return value would be to just pick some output and hope it was reasonable, after all. -- keith.pack...@intel.com pgpmj8wcKUsgr.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xserver: add monitor Option "ZoomModes"
v...@picaros.org writes: > The revised patch v2 is here below. Servaas. Aaron -- you reviewed the previous version of this patch; any chance you might read through this second version and see if it looks reasonable now? -- keith.pack...@intel.com pgpYpv0HUIHTT.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xf86: return NULL for xf86CompatOutput if config->compat_output is -1
On Mon, Mar 18, 2013 at 11:31:59AM -0700, Keith Packard wrote: > Aaron Plattner writes: > > > If there is no compat output, config->compat_output is -1 and > > xf86CompatOutput > > reads before the beginning of the outputs array. Didn't Dave send the fix for this? 1357701295-19913-1-git-send-email-airl...@gmail.com http://patchwork.freedesktop.org/patch/12803/ -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xrandr providers and offloading to displaylink usb card
On 07/01/13 07:03, Dave Airlie wrote: > On Mon, Jan 7, 2013 at 10:23 AM, Sam Lanning wrote: >> Hi There, >> >> I have a displaylink usb adapter which i have been trying to get working >> with my setup for a while. >> >> when i run >> >>> xrandr --listproviders >> i get the output >> >>> Providers: number : 2 >>> Provider 0: id: 106 cap: 0xb, Source Output, Sink Output, Sink Offload >>> crtcs: 2 outputs: 4 associated providers: 1 name:Intel >>> Provider 1: id: 68 cap: 0x2, Sink Output crtcs: 2 outputs: 3 associated >>> providers: 1 name:modesetting >> and after running the command >> >>> xrandr --setprovideroutputsource 68 106 >> I get 3 new outputs added to xrandr: >> >>> LVDS-0 disconnected >>> VGA-0 disconnected >>> HDMI-0 disconnected > that doesn't seem like displaylink to me, the driver will never create > LVDS outputs. > > Might want to confirm with a copy of the log file. > > Dave. Hey, It's been a while (busy with academia) but now i have some time to try and get this working again. I'm running on a laptop with optimus, i believe that the second provider listed above is actually my nvidia card. Now i am aware that the hdmi port is connected only to the nvidia card, this would match up nicely with what i have above, i.e. i activated my nvidia card, hence activating my hdmi output, along with the outputs of the other display ports (which are connected to both cards) So it seems my problem at the moment is this: I have (what i believe to be) the latest display link drivers installed. When i plug in my usb gpu, i have a new device listed under lsusb: > Bus 002 Device 008: ID 17e9:01d7 DisplayLink And a new corresponding framebuffer device /dev/fbx appears (although interestingly it is fb1 sometimes if plugged in at boot). So my question is, why is it not appearing after calling xrandr --listproviders (which shows only my integrated and nvidia cards). Any help would be greatly appreciated. Many Thanks, Sam. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xf86: return NULL for xf86CompatOutput if config->compat_output is -1
On Mon, Mar 18, 2013 at 06:47:23PM +, Chris Wilson wrote: > On Mon, Mar 18, 2013 at 11:31:59AM -0700, Keith Packard wrote: > > Aaron Plattner writes: > > > > > If there is no compat output, config->compat_output is -1 and > > > xf86CompatOutput > > > reads before the beginning of the outputs array. > > Didn't Dave send the fix for this? > 1357701295-19913-1-git-send-email-airl...@gmail.com > http://patchwork.freedesktop.org/patch/12803/ And for the record commit 3ec35c45ca17f5ed6fd02c50fc49ae7b8d128dcb Author: Dave Airlie Date: Wed Jan 9 12:53:14 2013 +1000 xf86: actually set the compat output in the failure case It certainly fixed the instances of -1 that I was hitting... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xf86: return NULL for xf86CompatOutput if config->compat_output is -1
On 03/18/2013 11:47 AM, Chris Wilson wrote: On Mon, Mar 18, 2013 at 11:31:59AM -0700, Keith Packard wrote: Aaron Plattner writes: If there is no compat output, config->compat_output is -1 and xf86CompatOutput reads before the beginning of the outputs array. Didn't Dave send the fix for this? 1357701295-19913-1-git-send-email-airl...@gmail.com http://patchwork.freedesktop.org/patch/12803/ My server should have that commit (3ec35c45ca17f5ed6fd02c50fc49ae7b8d128dcb). I'll step through it to see why I'm not getting a compat_output. I checked the callers and they all look like they'll correctly handle a NULL return from xf86CompatOutput, but it does also look like that's not supposed to actually happen. -- Aaron ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] -next for 1.15
On Mon, 18 Mar 2013, Keith Packard wrote:
> Peter Hutterer writes:
> > Peter Hutterer (13):
> > kdrive: fix "set but not used" warnings
>
> Merged.
>cf89aa5..116f020 master -> master
Is 4149ee8ec0193acbf3812c7ee2627b93b9a89997 the right fix for this?
I had locally committed the patch below, but I don't know how to test
it...
>From df9b47ee3e07b99d013926080963104098f2d319 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven
Date: Fri, 22 Feb 2013 13:28:28 +0100
Subject: [PATCH] Xfbdev: revive randr new screen size logic
hw/kdrive/fbdev/fbdev.c: In function 'fbdevRandRSetConfig':
hw/kdrive/fbdev/fbdev.c:470:19: warning: variable 'newheight' set but not used
[-Wunused-but-set-variable]
hw/kdrive/fbdev/fbdev.c:470:9: warning: variable 'newwidth' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Geert Uytterhoeven
---
hw/kdrive/fbdev/fbdev.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/hw/kdrive/fbdev/fbdev.c b/hw/kdrive/fbdev/fbdev.c
index a913f87..a8d36c6 100644
--- a/hw/kdrive/fbdev/fbdev.c
+++ b/hw/kdrive/fbdev/fbdev.c
@@ -465,15 +465,19 @@ fbdevRandRSetConfig(ScreenPtr pScreen,
int oldheight;
int oldmmwidth;
int oldmmheight;
-int newwidth, newheight;
+int newwidth, newheight, newmmwidth, newmmheight;
if (screen->randr & (RR_Rotate_0 | RR_Rotate_180)) {
newwidth = pSize->width;
newheight = pSize->height;
+newmmwidth = pSize->mmWidth;
+newmmheight = pSize->mmHeight;
}
else {
newwidth = pSize->height;
newheight = pSize->width;
+newmmwidth = pSize->mmHeight;
+newmmheight = pSize->mmWidth;
}
if (wasEnabled)
@@ -491,6 +495,10 @@ fbdevRandRSetConfig(ScreenPtr pScreen,
*/
scrpriv->randr = KdAddRotation(screen->randr, randr);
+pScreen->width = newwidth;
+pScreen->height = newheight;
+pScreen->mmWidth = newmmwidth;
+pScreen->mmHeight = newmmheight;
fbdevUnmapFramebuffer(screen);
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xrandr providers and offloading to displaylink usb card
On 03/18/2013 10:08 AM, Sam Lanning wrote: On 07/01/13 07:03, Dave Airlie wrote: On Mon, Jan 7, 2013 at 10:23 AM, Sam Lanning wrote: Hi There, I have a displaylink usb adapter which i have been trying to get working with my setup for a while. when i run xrandr --listproviders i get the output Providers: number : 2 Provider 0: id: 106 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 4 associated providers: 1 name:Intel Provider 1: id: 68 cap: 0x2, Sink Output crtcs: 2 outputs: 3 associated providers: 1 name:modesetting and after running the command xrandr --setprovideroutputsource 68 106 I get 3 new outputs added to xrandr: LVDS-0 disconnected VGA-0 disconnected HDMI-0 disconnected that doesn't seem like displaylink to me, the driver will never create LVDS outputs. Might want to confirm with a copy of the log file. Dave. Hey, It's been a while (busy with academia) but now i have some time to try and get this working again. I'm running on a laptop with optimus, i believe that the second provider listed above is actually my nvidia card. Now i am aware that the hdmi port is connected only to the nvidia card, this would match up nicely with what i have above, i.e. i activated my nvidia card, hence activating my hdmi output, along with the outputs of the other display ports (which are connected to both cards) So it seems my problem at the moment is this: I have (what i believe to be) the latest display link drivers installed. When i plug in my usb gpu, i have a new device listed under lsusb: Bus 002 Device 008: ID 17e9:01d7 DisplayLink And a new corresponding framebuffer device /dev/fbx appears (although interestingly it is fb1 sometimes if plugged in at boot). So my question is, why is it not appearing after calling xrandr --listproviders (which shows only my integrated and nvidia cards). Any help would be greatly appreciated. There are two DisplayLink drivers: udl, and udlfb. In my experience, the udlfb one creates a /dev/fb* device and is *not* a DRM driver. You need to unload and/or blacklist that one to let the udl driver do its thing. The udl driver creates outputs named DVI-*, even if it's really a VGA device. -- Aaron ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] glx: fix uninitialized var in __glXDRIscreenProbe
Piotr Dziwinski writes: > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59825 > > Signed-off-by: Piotr Dziwinski Merged. c2ede8f..cc3d1a5 master -> master -- keith.pack...@intel.com pgpfUKzeGqsgI.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/7] Xi: return !Success from DeliverTouchEmulatedEvent if we didn't deliver
Peter Hutterer writes: > Signed-off-by: Peter Hutterer Ok, this took more review than I would have though. Changing the return value assumes that all callers will be happy with the new value, in this case, I'm betting that no-one actually uses the value at this point. Here's an inverse call graph: DeliverTouchEmulatedEvent DeliverEmulatedMotionEvent Ignores value DeliverTouchBeginEvent DeliverTouchEvent DeliverTouchEvents Ignores value DeliverTouchEndEvent DeliverTouchEvent DeliverTouchEvents Ignores value In no case do these functions actually look at the value, they simply pass it up the call chain. Therefore, this patch will have 'no effect'. Reviewed-by: Keith Packard -- keith.pack...@intel.com pgpmYqakELCtm.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/7] Xi: use a temp variable for the new listener
Peter Hutterer writes: > Instead of accessing ti->listener[0] all the time. Reviewed-by: Keith Packard -- keith.pack...@intel.com pgpFAhOUnBO5b.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 3/7] dix: don't set non-exisiting flags on touch events
Peter Hutterer writes:
> server-internal defines that we need to convert to XI protocol defines.
> Currently only two of those defines actually translate to the protocol, so
> make sure we don't send internal garbage down the wire.
>
> No effect to current clients since they shouldn't look at undefined bits
> anyway.
>
> Signed-off-by: Peter Hutterer
> ---
> dix/eventconvert.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/dix/eventconvert.c b/dix/eventconvert.c
> index 2c411cf..ebc52c3 100644
> --- a/dix/eventconvert.c
> +++ b/dix/eventconvert.c
> @@ -684,17 +684,18 @@ eventToDeviceEvent(DeviceEvent *ev, xEvent **xi)
> xde->root_x = double_to_fp1616(ev->root_x + ev->root_x_frac);
> xde->root_y = double_to_fp1616(ev->root_y + ev->root_y_frac);
>
> -if (ev->type == ET_TouchUpdate)
> -xde->flags |= (ev->flags & TOUCH_PENDING_END) ? XITouchPendingEnd :
> 0;
> -else
> -xde->flags = ev->flags;
> +if (IsTouchEvent((InternalEvent *)ev)) {
> +if (ev->type == ET_TouchUpdate)
> +xde->flags |= (ev->flags & TOUCH_PENDING_END) ?
> XITouchPendingEnd : 0;
>
> -if (IsTouchEvent((InternalEvent *) ev) &&
> -ev->flags & TOUCH_POINTER_EMULATED)
> -xde->flags |= XITouchEmulatingPointer;
> +if (ev->flags & TOUCH_POINTER_EMULATED)
> +xde->flags |= XITouchEmulatingPointer;
> +} else {
> +xde->flags = ev->flags;
>
> -if (ev->key_repeat)
> -xde->flags |= XIKeyRepeat;
> +if (ev->key_repeat)
> +xde->flags |= XIKeyRepeat;
> +}
I think you want to leave XIKeyRepeat set for non-touch events, right?
--
keith.pack...@intel.com
pgpuBc5qfZaM5.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 4/7] dix: fix a comment
Peter Hutterer writes: > Signed-off-by: Peter Hutterer Reviewed-by: Keith Packard -- keith.pack...@intel.com pgpEtWGI0wQ43.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 5/7] Xi: compress two if statements with the same body
Peter Hutterer writes: > We do the same thing here, compress them into one body. > > Signed-off-by: Peter Hutterer Reviewed-by: Keith Packard -- keith.pack...@intel.com pgpr1a3wTU9L8.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 6/7] dix: update coords for touch events in PlayReleasedEvents
Peter Hutterer writes: > Signed-off-by: Peter Hutterer I'd note that this is only for Xinerama in the commit message Reviewed-by: Keith Packard -- keith.pack...@intel.com pgpU73Oz785PT.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 7/7] Xi: add a comment to make a condition a bit clearer
Peter Hutterer writes: > The commit message to 676447190190d8546165e21be242cf16dd69f5ae explains it, > but that doesn't stop the WTF moment when reading the code. > > Signed-off-by: Peter Hutterer Reviewed-by: Keith Packard -- keith.pack...@intel.com pgppE8moEFgnx.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
RE: [Glamor] glamor with xserver > 1.12
I tried it. Glamor does start successfully with the xserver latest git master version. Although it seems there is a regression when start FC17 with it. After a quick analysis, it should be a texture cache pool related bug. Junyan, if you have time, please look at this bug and try to fix it. Thanks. Its should be easily to reproduce. Use latest git master xserver, latest xf86-video-intel and start gnome-session on a FC17 distro. Then look at the top-right panels battery/volume icons, you may see some incorrect output, and if you disable the fbo pool cache, then it can fix that problem. From: xorg-devel-bounces+zhigang.gong=linux.intel@lists.x.org [mailto:xorg-devel-bounces+zhigang.gong=linux.intel@lists.x.org] On Behalf Of zhigang gong Sent: Monday, March 18, 2013 5:12 PM To: Michel Dänzer Cc: Alex B; Zhigang Gong; xorg-devel@lists.x.org; He, Junyan; gla...@lists.freedesktop.org Subject: Re: [Glamor] glamor with xserver > 1.12 Oh, Really? That's a great news for me, I will have a try tomorrow. But To be honest, even it works, such dependencies is still an issue. And I'm afraid it may break the indirect GLX's context somehow. As the GLX server side may have a different gl dispatch table from the mesa's. On Mon, Mar 18, 2013 at 4:48 PM, Michel Dänzer wrote: On Mon, 2013-03-18 at 16:40 +0800, Zhigang Gong wrote: > > -Original Message- ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xrandr providers and offloading to displaylink usb card
On 18/03/13 21:27, Aaron Plattner wrote: > On 03/18/2013 10:08 AM, Sam Lanning wrote: >> On 07/01/13 07:03, Dave Airlie wrote: >>> On Mon, Jan 7, 2013 at 10:23 AM, Sam Lanning >>> wrote: Hi There, I have a displaylink usb adapter which i have been trying to get working with my setup for a while. when i run > xrandr --listproviders i get the output > Providers: number : 2 > Provider 0: id: 106 cap: 0xb, Source Output, Sink Output, Sink > Offload > crtcs: 2 outputs: 4 associated providers: 1 name:Intel > Provider 1: id: 68 cap: 0x2, Sink Output crtcs: 2 outputs: 3 > associated > providers: 1 name:modesetting and after running the command > xrandr --setprovideroutputsource 68 106 I get 3 new outputs added to xrandr: > LVDS-0 disconnected > VGA-0 disconnected > HDMI-0 disconnected >>> that doesn't seem like displaylink to me, the driver will never create >>> LVDS outputs. >>> >>> Might want to confirm with a copy of the log file. >>> >>> Dave. >> Hey, >> >> It's been a while (busy with academia) but now i have some time to try >> and get this working again. >> >> I'm running on a laptop with optimus, i believe that the second provider >> listed above is actually my nvidia card. Now i am aware that the hdmi >> port is connected only to the nvidia card, this would match up nicely >> with what i have above, i.e. i activated my nvidia card, hence >> activating my hdmi output, along with the outputs of the other display >> ports (which are connected to both cards) >> >> So it seems my problem at the moment is this: >> >> I have (what i believe to be) the latest display link drivers installed. >> When i plug in my usb gpu, i have a new device listed under lsusb: >> >>> Bus 002 Device 008: ID 17e9:01d7 DisplayLink >> >> And a new corresponding framebuffer device /dev/fbx appears (although >> interestingly it is fb1 sometimes if plugged in at boot). >> >> So my question is, why is it not appearing after calling xrandr >> --listproviders (which shows only my integrated and nvidia cards). Any >> help would be greatly appreciated. > > There are two DisplayLink drivers: udl, and udlfb. In my experience, > the udlfb one creates a /dev/fb* device and is *not* a DRM driver. > You need to unload and/or blacklist that one to let the udl driver do > its thing. > > The udl driver creates outputs named DVI-*, even if it's really a VGA > device. > Thanks Aaron Ok so i unloaded and blocked udlfb. I am now getting sporadic results. Sometimes i can see my nvidia card in --listproviders and other times i can not. And I am still unable to get the displaylink adapter to appear in listproviders. I had one success though, in one instance in a fresh boot with udlfb blacklisted (udl also did not load automatically) i called modprobe udl, plugged in the displaylink usb gpu and it, along with the nvidia and intel cards appeared in --listproviders. I have been unable to reproduce this, and have since only been able to see the integrated intel card in this listing. I'm not entirely sure as to what is going on here, partiularly with the nvidia card sometimes showing up and sometimes not! Sam. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
