Re:Debugging multiple X11 servers spawning
> > 1. Re: Debugging multiple X11 servers spawning > Run top and see if there are multiple iterations of xinit running.
Re: Regarding X client
> > Message: 2 > Date: Tue, 27 Jun 2023 15:51:16 +0300 > From: Riza Dindir > To: xorg > Subject: Regarding X client > Message-ID: > > Hello All, > > I want to run two applications on X client, and have an xinitrc file > that starts a GTK application and another that starts xterm. Like so > > my-gui-app & > xterm > > I do not want to use a window manager for this. > > When I start the client with startx, it displays both of the > applications but the xterm does not have focus. > > If I click on the xterm window, the focus is not given to the xterm window. > > Is this default behavior? How can I focus on the xterm window? Using a > mouse? Or some other way? > > Regards, > Riza > Please post the entirety of you xinitrc file. You're saying you're starting X without a window manager? That's not even possible anymore, it was way back in the day but now X just immediately exits if there's no window manager to communicate with, or, at least that's what happens with my distribution (Slackware 15.0).
re: I only get VisibilityNotify events at window mapping
>
> Date: Sat, 17 Sep 2022 11:30:39 -0300
> From: Lucas de Sena
> To: xorg@lists.x.org
> Subject: I only get VisibilityNotify events at window mapping
> Message-ID:
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> I'm trying to get VisibilityNotify events to check whether a given
> window is obscured.
>
> However, I only get VisibilityNotify events after mapping the window.
> Obscuring it with any other window (be it a sibling or not) does not
> trigger a VisibilityNotify event, nor when I unobscure it.
>
> And when I get such event, the value of `ev.xvisibility.state` is always
> `VisibilityUnobscured`, even when mapping the window below others.
>
> Here's a sample program:
>
> #include
> #include
>
> int
> main(void)
> {
> Display *dpy;
> Window win;
> XEvent ev;
>
> if ((dpy = XOpenDisplay(NULL)) == NULL)
> return 1;
> win = XCreateWindow(
> dpy,
> XDefaultRootWindow(dpy),
> 0, 0,
> 100, 100,
> 0,
> CopyFromParent, InputOutput, CopyFromParent,
> CWEventMask | CWBackPixel,
> &(XSetWindowAttributes){
> .event_mask = VisibilityChangeMask,
> .background_pixel = BlackPixel(dpy, DefaultScreen(dpy)),
> }
> );
> XMapWindow(dpy, win);
> while (!XNextEvent(dpy, ))
> if (ev.type == VisibilityNotify)
> printf("visibility: %d\n", ev.xvisibility.state);
> return 0;
> }
>
> Is that how VisibilityNotify is supposed to work?
>
It works perfectly for me using MWM (Motif Window Manager)
Bug#1006605: xserver-xorg-video-radeon: on login; any desktop which has screen orientation saved as portrait logs out
Package: xserver-xorg-video-radeon Version: 1:19.1.0-2+b1 Severity: important X-Debbugs-Cc: guiv...@ubuntu.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Updates that led to this issue are Start-Date: 2022-02-24 22:36:20 Commandline: apt full-upgrade Requested-By: guiverc (1000) Install: xcvt:amd64 (0.1.1-3, automatic) Upgrade: xserver-xorg-video-nouveau:amd64 (1:1.0.17-1, 1:1.0.17-2), xserver- xorg-video-amdgpu:amd/rad64 (21.0.0-2, 21.0.0-2+b1), xserver-xorg-core:amd64 (2:1.20.14-1, 2:21.1.3-2+b1), xserver-xorg-video-intel:amd64 (2:2.99.917+git20200714-2, 2:2.99.917+git20210115-1), xserver-xorg-video- vesa:amd64 (1:2.5.0-1, 1:2.5.0-1+b1), xserver-xorg-legacy:amd64 (2:1.20.14-1, 2:21.1.3-2+b1), xserver-common:amd64 (2:1.20.14-1, 2:21.1.3-2), xserver-xorg- video-radeon:amd64 (1:19.1.0-2, 1:19.1.0-2+b1), xserver-xorg-video-vmware:amd64 (1:13.3.0-3, 1:13.3.0-3+b1), xserver-xorg-input-libinput:amd64 (1.2.0-1, 1.2.1-1+b1), xserver-xephyr:amd64 (2:1.20.14-1, 2:21.1.3-2+b1), xserver-xorg- video-ati:amd64 (1:19.1.0-2, 1:19.1.0-2+b1), xserver-xorg-video-fbdev:amd64 (1:0.5.0-1, 1:0.5.0-2), xserver-xorg-video-qxl:amd64 (0.1.5+git20200331-1, 0.1.5+git20200331-2) End-Date: 2022-02-24 22:36:41 Issue occurred on next login (the following day) * What exactly did you do (or not do) that was effective (or ineffective)? My system has multiple desktops installed & any that have a default config that matches my setup (landscape+portrait) allow screens to go black, cursor to draw then logout without message; this includes LXQt, Xfce, ... * What was the outcome of this action? Machine cannot be used by any installed desktop that had my screen orientation saved. * What outcome did you expect instead? Normal behavior - login gets my desktop drawn & allows me to use it. I've altered this GNOME to return to defaults so I have one display readable (other is orientated wrongly as it's sideways; setup is landscape as that works but monitor is portrait..) LXDE still logs in, but it didn't have screen orientation configured; however if I run the script xrandr --output HDMI-0 --mode 1280x1024 --pos 1280x0 --rotate left --output DVI-0 --primary --mode 1280x1024 --pos 0x0 --rotate normal --output VGA-0 --off which adjusts display to match my setup - instant logout !! In `sudo journalctl` I see the following when I run the `xrandr` command I just mentioned; I see equivalent on login via Xfce/LXQt/.. too; but I've copy/pasted from a LXDE session where I ran the `xrand` command Feb 28 20:31:48 dc780-deb kernel: [ cut here ] Feb 28 20:31:48 dc780-deb kernel: WARNING: CPU: 0 PID: 833 at drivers/gpu/drm/ttm/ttm_bo.c:411 ttm_bo_release+0x384/0x3b0 [ttm] Feb 28 20:31:48 dc780-deb kernel: Modules linked in: bnep snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscac> Feb 28 20:31:48 dc780-deb kernel: libcrc32c crc32c_generic amdgpu gpu_sched hid_generic usbhid hid sd_mod t10_pi uas crc_t10dif crct10dif_generic usb_storage sr_mod cdrom crct10dif_common > Feb 28 20:31:48 dc780-deb kernel: CPU: 0 PID: 833 Comm: Xorg Not tainted 5.16.0-1-amd64 #1 Debian 5.16.7-2 Feb 28 20:31:48 dc780-deb kernel: Hardware name: Dell Inc. OptiPlex 780 /0200DY, BIOS A03 02/13/2010 Feb 28 20:31:48 dc780-deb kernel: RIP: 0010:ttm_bo_release+0x384/0x3b0 [ttm] Feb 28 20:31:48 dc780-deb kernel: Code: 00 e8 50 ca 8a f2 48 8b 43 e8 eb a8 be 03 00 00 00 e8 f0 51 6c f2 e9 6f fd ff ff e8 c6 a7 8a f2 e9 65 fd ff ff 48 89 e8 eb 8a <0f> 0b e9 af fc ff ff > Feb 28 20:31:48 dc780-deb kernel: RSP: 0018:b47d40dabdf0 EFLAGS: 00010202 Feb 28 20:31:48 dc780-deb kernel: RAX: RBX: 921c063f3dd8 RCX: Feb 28 20:31:48 dc780-deb kernel: RDX: 0002 RSI: b374e32e RDI: 921c063f3dd8 Feb 28 20:31:48 dc780-deb kernel: RBP: 921c00b846f0 R08: 921c063f3dd8 R09: 0064 Feb 28 20:31:48 dc780-deb kernel: R10: 0010 R11: 921c04a98b68 R12: 921c063f3c78 Feb 28 20:31:48 dc780-deb kernel: R13: 921d2ffbf560 R14: 921c04699780 R15: Feb 28 20:31:48 dc780-deb kernel: FS: 7f1b35623ec0() GS:921d2fe0() knlGS: Feb 28 20:31:48 dc780-deb kernel: CS: 0010 DS: ES: CR0: 80050033 Feb 28 20:31:48 dc780-deb kernel: CR2: 7f89dea28a30 CR3: 0001159c CR4: 000406f0 Feb 28 20:31:48 dc780-deb kernel: Call Trace: Feb 28 20:31:48 dc780-deb kernel: Feb 28 20:31:48 dc780-deb kernel: ? __inode_wait_for_writeback+0x7e/0xe0 Feb 28 20:31:48 dc780-deb kernel: ? fsnotify_grab_connector+0x49/0x80 Feb 28 20:31:48 dc780-deb kernel: radeon_bo_unref+0x1a/0x30 [radeon] Feb 28 20:31:48 dc780-deb kernel: radeon_gem_object_free+0x30/0x50 [radeon] Feb 28 20:31:48 dc780-deb kernel: drm_gem_dmabuf_release+0x36/0x50 [drm] Feb 28
XInitThreads multiple times
Yes, that's kind of what it's for! Just make sure to lock (and unlock) the display in each thread. > > > > Hello, > > > > Is it possible to call |XInitThreads| multiple times, for example 20 > > times and not worry who calls it first? > > > > XInitThreads isn't re-entrant, so you need to ensure that it isn't > getting invoked by multiple threads in parallel, but it does check to > see if it has been called before, so it is safe to call multiple times > in sequence. > Also remember to lock (and unlock) the display in each thread.
Re: R128 errors
Hi Gene, Thanks for replying. I have no idea if it was a low volume card. You are probably right. I just need S-video so I can stream movies for the kids when they come over. I am thinking of going back to the Xorg.0.log file and looking at the list of cards that driver supports and seeing if I can get one still. What do you think? It would still be nice to get this ALL-IN-WONDER card running, but it is a strange beast; it does TV in. They likely had to change some things to get it to work. The more I think about it, the more I think you are correct. Best Regards, Chris On Sun, May 23, 2021 at 8:04 PM Gene Heskett wrote: > On Sunday 23 May 2021 14:33:27 Chris Fisichella wrote: > > > Hi, > > > > I am coming off of a previous post where I had just a black screen. > > That has changed. I can now access my Xorg.0.log file. It is attached. > > > And it looks like it gave it the old college try. And I don't see on a > 32 bit system, any reason why the address reported as out of range in > the EE lines, should be out of range. > > > If anyone who is familiar with the R128 driver can help debug what I > > need to do, I would appreciate it. > > > > The computer is a 32 bit machine. The video card is the ATI > > ALL-IN-WONDER 128 PRO. The operating system is Debian 10.9.0. > > What I do get the impression of, is that you are doing battle with a > frankenstein card, something ati has been quite famous for in my now 20+ > year old history, changing the card in the box, making it incompatible > with the published drivers for linux, without updateing a single crossed > t or dotted i on the box. Plain and simple it was not the card I bought > but the next production run. I yelled at ati, and was promised linux > drivers for that chipset would be announced in about 2 weeks. Never > happened, and I wasted almost $85 running out to buy it in about 1999. > > At least the $29 nvidia card worked with the vesa driver. But that > experience taught me to not believe a thing Alex tells me. YMMV. > > > The driver seems to be identifying the card okay. I don't know why it > > is still generating errors. Any ideas? > > > > Best Regards, > > Chris > > > Cheers, Gene Heskett > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > If we desire respect for the law, we must first make the law respectable. > - Louis D. Brandeis > Genes Web page <http://geneslinuxbox.net:6309/gene> > ___ > xorg@lists.x.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: https://lists.x.org/mailman/listinfo/xorg > Your subscription address: %(user_address)s > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
R128 errors
Hi, I am coming off of a previous post where I had just a black screen. That has changed. I can now access my Xorg.0.log file. It is attached. If anyone who is familiar with the R128 driver can help debug what I need to do, I would appreciate it. The computer is a 32 bit machine. The video card is the ATI ALL-IN-WONDER 128 PRO. The operating system is Debian 10.9.0. The driver seems to be identifying the card okay. I don't know why it is still generating errors. Any ideas? Best Regards, Chris [30.886] X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 [30.886] Build Operating System: Linux 4.19.0-16-amd64 i686 Debian [30.886] Current Operating System: Linux Debian130071 4.19.0-16-686-pae #1 SMP Debian 4.19.181-1 (2021-03-19) i686 [30.886] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-16-686-pae root=/dev/mapper/Debian130071--vg-root ro quiet [30.886] Build Date: 19 April 2021 09:34:38AM [30.886] xorg-server 2:1.20.4-1+deb10u3 (https://www.debian.org/support) [30.886] Current version of pixman: 0.36.0 [30.886] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [30.886] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [30.886] (==) Log file: "/var/log/Xorg.0.log", Time: Sun May 23 12:19:35 2021 [30.993] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [31.144] (==) No Layout section. Using the first Screen section. [31.144] (==) No screen section available. Using defaults. [31.144] (**) |-->Screen "Default Screen Section" (0) [31.144] (**) | |-->Monitor "" [31.175] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [31.175] (==) Automatically adding devices [31.175] (==) Automatically enabling devices [31.175] (==) Automatically adding GPU devices [31.175] (==) Max clients allowed: 256, resource mask: 0x1f [31.284] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [31.284] Entry deleted from font path. [31.409] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [31.409] (==) ModulePath set to "/usr/lib/xorg/modules" [31.409] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [31.409] (II) Loader magic: 0x68a740 [31.409] (II) Module ABI versions: [31.409] X.Org ANSI C Emulation: 0.4 [31.409] X.Org Video Driver: 24.0 [31.409] X.Org XInput driver : 24.1 [31.409] X.Org Server Extension : 10.0 [31.411] (++) using VT number 7 [31.411] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [31.412] (II) xfree86: Adding drm device (/dev/dri/card0) [31.427] (--) PCI: (0@0:2:0) 8086:2972:1462:7336 rev 2, Mem @ 0xfdb0/1048576, 0xd000/268435456, I/O @ 0xff00/8 [31.427] (--) PCI:*(2@0:0:0) 1002:5446:1002:0029 rev 0, Mem @ 0xf800/67108864, 0xfdcf8000/16384, I/O @ 0xec00/256, BIOS @ 0x/131072 [31.453] (II) LoadModule: "glx" [31.498] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [31.761] (II) Module glx: vendor="X.Org Foundation" [31.761] compiled for 1.20.4, module version = 1.0.0 [31.761] ABI class: X.Org Server Extension, version 10.0 [31.761] (==) Matched ati as autoconfigured driver 0 [31.761] (==) Matched modesetting as autoconfigured driver 1 [31.761] (==) Matched fbdev as autoconfigured driver 2 [31.761] (==) Matched vesa as autoconfigured driver 3 [31.761] (==) Assigned the driver to the xf86ConfigLayout [31.761] (II) LoadModule: "ati" [31.775] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so [31.790] (II) Module ati: vendor="X.Org Foundation" [31.790] compiled for 1.20.4, module version = 19.0.1 [31.790] Module class: X.Org Video Driver [31.790] ABI class: X.Org Video Driver, version 24.0 [31.790] (II) LoadModule: "r128" [31.790] (II) Loading /usr/lib/xorg/modules/drivers/r128_drv.so [31.817] (II) Module r128: vendor="X.Org Foundation" [31.817] compiled for 1.20.3, module version = 6.12.0 [31.817] Module class: X.Org Video Driver [31.817] ABI class: X.Org Video Driver, version 24.0 [31.817] (II) LoadModule: "modesetting" [31.817] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [31.859] (II) Module modesetting: vendor="X.Org Foundation
No screen, no prompt
Hi, As part of a Debian 10.9.0 install on a 32 bit machine, X was installed. I am trying to get an ATI ALL-IN-WONDER 128 PRO card to work in this machine so I can show movies to my kids. It used to boot to at least "Cannot show this video mode" or something like that. I could press ctrl-alt-F5 or F6. I never quite figured out which one. That allows me to get to a root prompt. I can then read the xorg log file. I saw on a list to remove the xorg.conf file. I did not see one, but I did see an xorg.conf.d directory, which I renamed and then rebooted. Now, it still boots to a black screen. I cannot get to a root prompt to access the xorg log file. I am trying to trouble shoot some (EE) statements I am seeing. Does anyone have any idea what to do to get that root prompt back? Best Regards, Chris ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Stale image on X11 server after lost connection
> > Re: Stale image on X11 server after lost connection > > Message: 1 >Date: Tue, 6 Apr 2021 14:05:26 +0200 > From: Jos? Tom?s Tocino Garc?a > To: Ilya Anfimov , xorg@lists.x.org > Subject: Re: Stale image on X11 server after lost connection > Message-ID: > > I'm sorry for the late reply. I've realized I made a mistake in the initial > post, the server is actually running motif windows manager. > > The output of xlsclients is: > > # xlsclients -al > Window 0x60005b: > Machine: localhost.localdomain > Name: mwm > Icon Name: mwm > Command: /usr/bin/mwm > Instance/Class: mwm/Mwm > Give this a try: Right click the desktop, the root menu should popup, select "Restart..." ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
How to get the current cursor of a Window?
I can set the cursor to be displayed on a window in a XSetWindowAttributes(3) structure while creating a window, or with XDefineCursor(3) after the window is created. But how can I get the current cursor of a window? The XWindowAttributes(3) structure does not contain a Cursor entry, so I cannot query it with XGetWindowAttributes(3). Thanks in advance. XQueryPointer ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Beginner Questions About XCB - xcb_alloc_color is too slow
Around 25 years ago, before the X Render Extension, Eric Foster-Johnson
wrote a great article on the topic of using color in X, for the "Cross
Thoughts" column in Unix Review Magazine. I've kept a copy ever since:
When the X Window system became popular, particularly on UNIX
workstations, you were lucky if you had a display that supported 256
colors. At the time, most X programmers used the simplest color
functions because most workstations didn't provide more than the
simplest color displays.
Cross Thoughts
In recent years that's all changed and we now expect even low-end
hardware to display thousands of colors. Even so, most X programs
still stick to old habits and don't take advantage of the greater
color capabilities that X provides.
This month we'll go over color programming, starting from setting up
colors in a colormap to using more-complicated X visuals.
X builds its color model on RGB components, the red, green, and blue
values used to define color on a typical monitor. Using the Xcms
routines, short for X color management system, you can define colors
in terms of CIE (a color model defined in 1931 that represents all
possible colors in a three-dimensional color space)1 or HSV (hue
saturation value) definitions, but the Xcms routines translate either
definition to the RGB values the X server requires.
In X, the RGB values go from 0 (all off) to 65535 (all on). Many
color definitions that you'll find, though, go from 0 to 255. It's
not that hard to convert with a macro such as the following:
#define Conv256To64K(v) \
((65535 * (long) v)/256)
Whatever method you use, if you start with RGB values, you need to
follow the X scale of 0 to 65535.
You can allocate color cells from a colormap using RGB values. Or,
you can look up colors by name from a color database. X provides a
database of more than 700 color names (most of them shades of gray,
though). Each color in the database is defined with RGB values
(interestingly, using a range of 0 to 255). You can look up common
colors by name with the XLookupColor function:
Status XLookupColor(
Display* display,
Colormap colormap,
char* colorName,
XColor* rgbColor, /* RETURN */
XColor* hardwareColor) /* RETURN */
On success, XLookupColor returns a nonzero value and fills in the two
XColor structures. XLookupColor fills up the rgbColor structure with
the red, green, and blue components as read in from the color
database. XLookupColor also fills the hardwareColor structure with
the closest match to the color definition that is supported on your
hardware. Because of this, I tend to use the hardwareColor structure
rather than the rgbColor structure.
In both cases, the XColor structure holds the following values:
typedef struct {
unsigned long pixel;
unsigned short red, green, blue;
char flags;
char pad;
} XColor;
XLookupColor fills in the red, green, and blue fields, along with the
flags, which indicate which of the fields were used by bitmasks:
DoRed, DoGreen, and DoBlue, respectively.
You can then allocate cells in a colormap from the color definitions
held in the XColor structures filled in by XLookupColor. X calls
these color cells pixels, which aren't dots on the screen, but values
that represent a position in a colormap that holds a given color. In
simple colormaps, the pixel is merely an index into an array. This is
not always the case though, as we'll discuss later.
To allocate a color cell, call XAllocColor:
Status XAllocColor(
Display* display,
Colormap colormap,
XColor* hardwareColor) /* in/out */
The XColor pointer is both an input and output parameter. On input,
XAllocColor reads the RGB values and flags fields in the structure.
On completion, XAllocColor fills in the pixel field with the pixel
value for that color in the passed-in colormap.
Before allocating a new color cell, XAllocColor checks if a color
cell already holds the given RGB values in the colormap you pass in.
This lets applications share common color cells, say, for red or
gray. If you pass in the default colormap, chances are most common
colors are already allocated.
On success, you can use the pixel field for drawing. With the X
library, you can call XSetForeground to store the color into a
graphic context as the drawing color:
int XSetForeground(
Display * display,
GC gc,
unsigned long pixel)
With a Motif application, you can use the pixel value to set the
foreground or background resources for a widget. For example:
XtVaSetValues(widget,
XmNforeground,
hardwareColor.pixel,
NULL);
You can also combine the tasks of looking up a color from a name and
allocating a cell with XAllocNamedColor.
Both XAllocColor and XAllocNamedColor allocate read-only color cells.
That is, once set, you cannot change the definition of the color in
that cell. Because of this, multiple applications, using the same
colormap, can share the same colors.
It's slightly more difficult to allocate cells that you can change
later, called read-write color cells. To do this, call
Cant set my xkb's xkeymap with xkbcomp
Date: Thu, 17 Dec 2020 13:41:58 -0500 From: "James K. Lowden" To: xorg@lists.x.org Subject: Re: Cant set my xkb's xkeymap with xkbcomp Message-ID: <20201217134158.c0ce6bdbab5366a77fb64...@schemamania.org> Content-Type: text/plain; charset=ISO-8859-1 If the warning occurs on every system and can be ignored, what purpose do they serve? It's equal-opportunity code; it also catches errors that are significant and shouldn't be ignored. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: ANN: xterm-362
On 11/12/2020 06:35 PM, Thomas Dickey wrote: On Thu, Nov 12, 2020 at 05:05:54PM -0600, Chris Sorenson wrote: ... > A trivial patch to escape three apostrophes in configure.in that break > syntax highlighting in some editors (feel free to ignore!): Some work may be needed on the editors. The first two chunks cause the messages to be changed, adding an unnecessary backslash: ./configure --help ... --enable-load-vt-fonts enable load-vt-fonts() action --enable-loggingenable logging --enable-logfile-exec enable exec\'d logfile filter --disable-maximize disable actions for iconify/deiconify/maximize/restore --disable-num-lock disable NumLock keypad support ... and ./configure checking if you want direct-color support... yes checking if you want blinking cursor... yes checking if you want to ignore Linux\'s broken palette-strings... yes checking if you want to allow broken string-terminators... yes checking if you want to compile-in icon data... yes The unaltered script displays properly in vi-like-emacs... My apologies, I only checked that configure ran to completion and didn't notice the escapes were leaking through. I should have known better, escaping apostrophes is something I've been doing for years in Perl, I should have known better than to think it would work the same way in the shell. Definitely ignore the patch! Thanks for all the work you (and many others of course) do on X! ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: ANN: xterm-362
Message: 1 Date: Thu, 12 Nov 2020 00:52:17 + From: Thomas Dickey To: Xorg list , XFree86 Developers' list Subject: ANN: xterm-362 Message-ID: <20201112005217.3unjdgygmco6s...@prl-debianold-64.jexium-island.net> Content-Type: text/plain; charset="utf-8" Files: ftp://ftp.invisible-island.net/xterm/current/xterm-362.tgz ftp://ftp.invisible-island.net/xterm/current/xterm-362.tgz.asc ftp://ftp.invisible-island.net/xterm/patches/xterm-362.patch.gz ftp://ftp.invisible-island.net/xterm/patches/xterm-362.patch.gz.asc ftp://ftp.invisible-island.net/xterm/xterm-362.tgz ftp://ftp.invisible-island.net/xterm/xterm-362.tgz.asc Patch #362 - 2020/11/11 * cleanup of calls to free, removing checks for null (Walter Harms). * improved mouse-button reporting (prompted by discussion with Stephane Chazelas) + narrow the scope of the change for shift-key in patch #361 to make it apply only when the modifyOtherKeys resource is set to 2 (i.e., ?program mode?). Also, when checking the shift-key, ignore modifiers other than shift, control and ?meta? + usethe alt/meta modifier information obtained in VTInitModifiers to replace a hard-coded mod1 used to detect ?Meta? for mouse-button responses. * reduce SIGWINCH's sent to the client by filtering out duplicates. * improve display when scaleHeight is greater than 1: + the text-cursor is vertically-centered on the current line, rather than only extending below the current line (report by Manu Chaturvedi). + the built-in line-drawing characters extend to the scaled cell-height. * fill-in special case for motion-events to match the changes for shift-key in pointer-button events from patch #361. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net Lovely, thank you Thomas! A trivial patch to escape three apostrophes in configure.in that break syntax highlighting in some editors (feel free to ignore!): --- configure.in2020-09-19 11:50:26.0 -0500 +++ configure.ac2020-11-12 16:42:25.053827377 -0600 @@ -524,7 +524,7 @@ AC_MSG_RESULT($enable_blink_curs) test "$enable_blink_curs" = no && AC_DEFINE(OPT_BLINK_CURS,0,[Define to 0 to disable support for blinking cursor]) -AC_MSG_CHECKING(if you want to ignore Linux's broken palette-strings) +AC_MSG_CHECKING(if you want to ignore Linux\'s broken palette-strings) case $host_os in (linux*) @@ -764,7 +764,7 @@ AC_DEFINE(ALLOWLOGGING,1,[if you want support for logging]) AC_MSG_CHECKING(if you want to allow logging via a pipe) CF_ARG_ENABLE(logfile-exec, - [ --enable-logfile-exec enable exec'd logfile filter], + [ --enable-logfile-exec enable exec\'d logfile filter], [enable_log_exec=yes], [enable_log_exec=no]) AC_MSG_RESULT($enable_log_exec) @@ -1116,7 +1116,7 @@ dnl FIXME - extra test needed to make tcap-fkeys work on HPUX AC_CHECK_FUNCS(tigetstr) -dnl only check for ncurses' use_extended_names if really not using termcap +dnl only check for ncurses\' use_extended_names if really not using termcap if test -n "$cf_cv_lib_part_tgetent"; then AC_CHECK_FUNCS(use_extended_names) fi ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: poly line issue
My reasoning is: Entire shape is within clipping/bounding (as far as I can see at least), the line joins should "join correctly", the polylines consist of the same points (another test I made) but still the diamond is only rendered correctly if the rightmost corner is first/last. To me this seems inconsistent. How does it render on your machine? Using the code from the first post in this thread, on my computer all eight triangles render perfectly. Which is to say, they render without any missing pixels. I'm using: xcb-1.14 xcb-proto-1.14.1 xcb-util-0.4.0 xcb-util-cursor-0.1.3 xcb-util-errors-1.0 xcb-util-image-0.4.0 xcb-util-keysyms-0.4.0 xcb-util-renderutil-0.3.9 xcb-util-wm-0.4.1 and: X11-1.6.12 ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xdm-config for :0 doesn't call Xstartup?
Those snippets from your scripts look correct, is your sessreg set to executable? Does anyone else have access to your system? Might it have been hacked to prevent programs like "w," "who," or "lastlog" from showing that someone's ghosted in for nefarious purposes? On 10/18/2020 05:11 PM, IL Ka wrote: > > On Sun, Oct 18, 2020 at 5:35 PM Chris Sorenson wrote: > Hello. > > xdm runs Xstartup on behalf of the user. > Hmm.. man page says: "After the user logs in, xdm runs the Xstartup script as root.". There is a $USER argument passed to this script, but the script itself runs as root. > > What does your Xstartup say? > exec /usr/bin/sessreg -a -w /var/log/wtmp -u /var/run/utmp -x /usr/lib64/X11/xdm/Xservers -l $DISPLAY -h "" $USER I am pretty sure the problem is the following line in xdm-config: DisplayManager*startup: /usr/lib64/X11/xdm/Xstartup ! The following three resources set up display :0 as the console. DisplayManager._0.startup: /usr/lib64/X11/xdm/GiveConsole GiveConsole is: chown $USER /dev/console So, sessreg is simply not called when xdm serves screen :0 I was able to fix it by copying sessreg line to the GiveConsole, but it looks like a strange hack.. Ilya ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xdm-config for :0 doesn't call Xstartup?
xdm runs Xstartup on behalf of the user. Or, at least it's supposed to. Xstartup should then call sessreg which should invoke wtmp and utmp. However, it's possible to bypass wtmp/utmp by passing "-w none" to sessreg, in which case "w" won't show the login. What does your Xstartup say? On 10/18/2020 07:00 AM, xorg-requ...@lists.x.org wrote: Message: 1 Date: Sun, 18 Oct 2020 00:12:22 +0300 From: IL Ka To: xorg Subject: xdm-config for :0 doesn't call Xstartup? Message-ID: Content-Type: text/plain; charset="utf-8" Hello. I found that xdm-config has the following lines DisplayManager*startup: /usr/lib64/X11/xdm/Xstartup DisplayManager._0.startup: /usr/lib64/X11/xdm/GiveConsole As I understand, that means GiveConsole is run instead of Xstartup, so sessreg is not called, and I do not see my login in "w" output. I am sure this is how it worked for decades, so it could be that I misunderstand something. Is it a bug? Ilya. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
How to switch to a particular resolution? Xorg complains "No valid modes for "DFP-1:2560x1600"; removing." and ignores my setting.
On 9/23/20 1:35 PM, Yuri wrote:
> On 2020-09-23 08:21, Pete Wright wrote:
> > $ xrandr |grep 2560
>
>
> Interestingly, this command shows nothing after Xorg was started,
> but shows 2560x1600 after the "NVidia settings" program changes
> the resolution to 2560x1600.
>
> I just need to find a way, if any, to do this automatically.
>
I think we need a better picture of what's actually connected to
your system and what it's reporting itself as capable of. The full
output of xrandr would help, and it would also help to add
Option "ModeDebug"
to the "Device" or "Screen" section of /etc/X11/xorg.conf, restart
the X server, and the attach /var/log/Xorg.0.log.
Also, and sorry to be so blatantly obvious, but are you sure the Nvidia
kernel module is running?
('lsmod' will tell you)...
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
Re: Xorg freezes
Message: 2 Date: Wed, 4 Dec 2019 11:41:49 +0530 From: Fabin Mundattil To: x...@freedesktop.org Subject: Xorg freezes Message-ID: Content-Type: text/plain; charset="utf-8" I have Ubuntu 18 running Google Chrome. Google chrome freezes my machine. I figured it out that the hardware acceleration is the issue. From what I understand, something like this shouldn't freeze Xorg. I need to disable GLX, DRI2 and DRI3 in Xorg to fix the issue. I don't see any errors anywhere in logs either. Is this a bug in Xorg? Should I submit any more information? -- Regards Fabin M Message: 3 Date: Wed, 4 Dec 2019 10:54:13 +0100 From: Michel Dänzer To: Fabin Mundattil Cc: x...@freedesktop.org Subject: Re: Xorg freezes Message-ID: <9d22380b-f6c2-25ca-a296-5a56a309a...@daenzer.net> Content-Type: text/plain; charset=utf-8 On 2019-12-04 7:11 a.m., Fabin Mundattil wrote: I have Ubuntu 18 running Google Chrome. Google chrome freezes my machine. I figured it out that the hardware acceleration is the issue. From what I understand, something like this shouldn't freeze Xorg. I need to disable GLX, DRI2 and DRI3 in Xorg to fix the issue. I don't see any errors anywhere in logs either. Is this a bug in Xorg? More likely in the Mesa/kernel drivers you're using. -- Message: 4 Date: Wed, 04 Dec 2019 11:27:42 +0100 From: walter harms To: xorg@lists.x.org Cc: mfa...@gmail.com Subject: Re: Xorg freezes Message-ID: <5de78a1e.7060...@bfs.de> Content-Type: text/plain; charset=UTF-8 Am 04.12.2019 07:11, schrieb Fabin Mundattil: I have Ubuntu 18 running Google Chrome. Google chrome freezes my machine. I figured it out that the hardware acceleration is the issue. From what I understand, something like this shouldn't freeze Xorg. I need to disable GLX, DRI2 and DRI3 in Xorg to fix the issue. I don't see any errors anywhere in logs either. Is this a bug in Xorg? Should I submit any more information? Hi Fabin, independent of everything: The big problem for developers is replication, if the problem is not reproduceable it is less likely that it can be fixed. So if you want to submit a problem report take the seat of the developer and ask yourself: could you replicate the problem with that information ? It helps a lot if you can reduce the number of libraries needed etc. just my 2 cents, re, wh Regards Fabian, In particular, it would help to know what graphics hardware exists on your system. If there are binary kernel modules for that hardware from its manufacturer it would likely be best if you used those, though that is admittedly not the "free software" way. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Using Intel GPU "TearFree" option changes my detected screens / edid information
I tested this on multiple machines and on both Debian 9 and 10 (with X11, not wayland). Is this a bug, or what is the explanation for this? Reply to both list an OP. I did a diff on those two xrandr outputs, there's a lot going on there. Intel is very wishy-washy about their graphics drivers. First thing to check would probably be how far off your Debian is compared to what Intel thinks your system should be using with their drivers (hyperlink): https://01.org/linuxgraphics/downloads/2018q1-intel-graphics-stack-recipe ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Regrabbing (was: Re: Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events)
[adding xorg@lists.x.org to CC, dropping t...@security.debian.org; please retain all CCs] Dear Xorg developers, > […] I recently became a co-maintainer for the xtrlock screen locking utility. As part of this, I noticed a bug report filed by Antoine Amarilli which points out that so-called multitouch events are not blocked when xtrlock is enabled: https://bugs.debian.org/830726 This means that some applications (notably Chromium) can still be controlled even when the machine is locked down. When I looked at the code and the documentation regarding multitouch events, this was "to be expected" due to it only calling the XGrabPointer function. I therefore extended the code to enumerate over all multitouch devices and lock them too via XIGrabDevice as part of the version 2 of the X Input Extensions: https://bugs.debian.org/830726#43 However, Antoine then pointed out that this would not prevent an attacker plugging in such a multitouch device *after* xtrlock has been started and thus permit controlling the desktop. I thus revised the patch to detect the introduction of the new device via the XI_HierarchyChanged event: https://bugs.debian.org/830726#65 This appeared to work initially but we were seeing some strange behaviour where the touchscreen is not "correctly" grabbed; one can still work around the grab using multiple fingers (eg. press somewhere, then interact with Chromium) but some even weirder behaviour whereby grabs will persist *after* the xtrlock process has ended! For more detail about this, please see: https://bugs.debian.org/830726#90 I would be interested in your input here. Hopefully I am doing something obviously bogus which you will be able to point out for a quick and easy fix but I have a gut feel something deeper is awry given that locks persist beyond the end of the process. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
RE: [ANNOUNCE] libXt 1.2.0
Today's Topics: 1. [ANNOUNCE] libXt 1.2.0 (Thomas Dickey) 2. [ANNOUNCE] libXt 1.2.0 (Thomas Dickey) Alan Coopersmith (3): Get rid of some extraneous ; at the end of C source lines Update README for gitlab migration Update configure.ac bug URL for gitlab migration Benjamin Tissoires (3): Fix leaks detected by covscan dummy fix for covscan Fix covscan complain Emil Velikov (1): autogen.sh: use quoted string variables Fabrice Fontaine (1): libXt: util: don't link makestrs with target cflags Jeremy Huddleston Sequoia (1): darwin: Don't build libXt with -flat_namespace Jon Turney (2): Fix WHITEFILL after const fixes Provide suseconds_t typedef on Win32 Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish Rin Okuyama (1): avoid -Wformat errors from clang when building with -DDEBUG Thomas E. Dickey (134): fix build when XT_GEO_TATTLER is defined Thanks for your work on this guys, those of us who still depend professionally on Xt and Motif really appreciate it! Now, can you please remove "Xt is a similarly deprecated library for building toolkits" from the wiki at x dot org? This work, and since Motif is still supported (sort of; not a real fan of ICS these days) are obvious proof that Xt is not deprecated. Thanks again, Chris ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xorg Digest, Vol 167, Issue 9
Hey guys, I hope this message isn't an annoyance but I'm not sure the best place to turn right now. I am having an issue with my X windows not getting "erased" when the window is closed. I'm probably not explaining well which is why my google searches have been empty. Basically I am running MWM as my window manager and opening an Xterm then exiting the xterm, after this the xterm window is still displayed but does not respond. I checked xwininfo and I see no reference to the window that I closed so I feel like the window was destroyed. Another interesting observation is that if I take another good window and drag it over the bad window, the good window will slide under the bad window. Its very strange. Lastly I have the NVIDIA driver installed (430.26) and this issue only happens when the COMPOSITE extension is disabled. Sorry again to bug everyone. Thanks. So it’s either an Nvidia problem or an MWM problem. I’m using MWM from version 2.1.32 (that I compiled myself), also with an Nvidia driver (GeForce though) and it’s working great. What version of Motif do you have? Releases from 2.2 and up have been pretty buggy. The Open Group still considers the 2.1 branch to be the official/stable branch. From http://www.ist-inc.com/motif/download : "Please note that the OpenMotif (2.2 or 2.3) distribution that is supplied with many Linux distributions has been classified as 'experimental' by the Open Group." On the other hand if it's an Nvidia problem, you probably want to post this on devtalk.nvidia.com, 430.26 is a very recent release, could be a regression or a bug that's crept in, did you see this problem with earlier versions of the 430 series? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xorg Digest: Corrupt window
Message: 1 Date: Mon, 17 Jun 2019 15:01:50 -0700 From: Andrew Kurn To: xorg@lists.x.org Subject: Corrupt window Message-ID: <20190617220150.GA2042@Godzilla.local> Content-Type: text/plain; charset=us-ascii I'm using the version of X current for Debian Jessie. I find that windows are sometimes corrupted. The typical case is in XTerm, when the bottom line is covered by a copy of the second-last line. It happens a little more than half the time, so some sort of race condition. It is not confined to XTerm; Emacs and Aisleriot show some of the same behavior. In all cases, moving the window will cure the problem. The redraw is correct. So my conclusion is it's a fault in X. I've never had to report an X bug before. If you will give me a list of info to provide, I will send it in a later message. Otherwise, thanks for your attention. Andrew Your graphics hardware? If you don't know, `lspci -vv` will list everything connected to your PCI bus, but please parse out the graphics info rather than replying with the whole list. Also, on the very unlikely possibility that it's a termcap issue, from an xterm window; what does `echo $TERM` tell you? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xorg Digest, Vol 165, Issue 6
Message: 1 Date: Tue, 9 Apr 2019 15:37:28 +1200 From: XJDHDR To: x...@freedesktop.org Subject: Re: "XKB: Could not invoke xkbcomp" error Message-ID: <4d717514-d25f-92d5-9c1e-2af6c41cf...@gmail.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" Thank you for helping. I am wondering: Am I supposed to setup /x11-xkb-utils/ in any way? The log file does mention that "/This [problem] could be a missing or incorrect setup of xkeyboard-config./" Do I need to create one after installing or is the installation doing this automatically? Kind regards On 2019/04/08 06:25, Samy Mahmoudi wrote: You should not have to create one, X is supposed to be supplied (by your distro) with a complete set of internationalized keyboard-config files, on my system they're installed in /usr/share/locale, you can look for them on yours by doing something like find /usr/share -name xkeyboard-config\* - if that finds nothing try find /usr -name xkeyboard-config\* What does dmesg | egrep -i keyboard tell you? Also please post the output of egrep -i keyboard /var/log/Xorg.log.0 and egrep xkb /var/log/Xorg.log.0 (or wherever your system locates your Xorg log). ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Xorg setting low resolution with double HDMI output despite forcing to full HD
Quoting Felix Miata (2019-02-21 12:05:36) > Francesco Nwokeka composed on 2019-02-21 10:45 (UTC+0100): > > > I have an Intel NUC with dual HDMI output. Recently I've been > > experiencing > > a problem with the output resolution of the screens. When booting the > > system i > > get screen resolution inferior to what I actually try to set via .xinitrc > > file: > > > xrandr --output $(xrandr -q | grep "\sconnected\s" | cut -f1 -d" ") --mode > > 1920x1080 > > Note in the log the string onnected does not appear. AFAICT, only the use of > xf86-video-intel DDX > driver, which last had an official release in 2015, causes that omission. > > > local/xf86-video-intel 1:2.99.917+859+g33ee0c3b-1 (xorg-drivers) > > > Does anyone have any idea to what might be the problem/solution? > > Easier solution is to purge xf86-video-intel, which when server version is > 1.17.0 or higher, should > automagically cause utilization of the newer modesetting DDX driver on X > restart or reboot. Other > option is to reconfigure /etc/X11/xorg.conf.d/50-device.conf to specify > driver modesetting. The DDX > modesetting driver does not have its own package. Instead it's the default, > provided by the server > package. Ahem. The ddx is doing exactly what it is being told to do. -Chris ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xorg Digest, Vol 163, Issue 8
My xKeyboard-config is version 2.23.1-1 (so it is the most recent version). This keyboard issue seems pretty common for Nedit users, which is why Nedit lists it in the "Help->Problems/Defects" option. I am quoting the text here: QUOTE P: Dialogs don't automatically get keyboard focus when they pop up. S: Most X Window managers allow you to choose between two categories of keyboard focus models: pointer focus, and explicit focus. Pointer focus means that as you move the mouse around the screen, the window under the mouse automatically gets the keyboard focus. NEdit users who use this focus model should set "Popups Under Pointer" in the Default Settings sub menu of the preferences menu in NEdit. Users with the explicit focus model, in some cases, may have problems with certain dialogs, such as Find and Replace. In MWM this is caused by the mwm resource startupKeyFocus being set to False (generally a bad choice for explicit focus users). NCDwm users should use the focus model "click" instead of "explicit", again, unless you have set it that way to correct specific problems, this is the appropriate setting for most explicit focus users. UNQUOTE So I followed this advice and tried to set the "Popups under pointer" option, but it was selected by default. Then why am I facing this problem? Anyway, I unselect it and restart Nedit, but this does NOT solve the problem. So I set the "popups under pointer" option AGAIN and restart Nedit. This time, It works FINE and all dialogs automatically have keyboard focus when opened. HOWEVER, when I open a second file in a second tab, the problem resurfaces. Is this a bug in NEdit? I don't think it's a bug in nedit, more likely an incompatibility in the window manager, what window manager are you using? Try starting Nedit in server mode (use the "nc" command instead of "nedit," then try opening a file in a new tab, does that solve the problem? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xorg Digest, Vol 163, Issue 8
On 02/15/2019 11:48 AM, akshay chavan wrote: Hi, Nedit's "version" option shows the following information: NEdit 5.6 Jul 5, 2010 Built on: Win32, x86-64, GNU C Built at: Jun 30 2015, 16:55:01 With Motif: (Untested) 2.3.4 [@(#)Motif Version 2.3.4] Running Motif: 2.3 [unknown] Server: The Cygwin/X Project 12001000 Visual: 24-bit TrueColor (ID 0x21, Default) Locale: en_US I did not build NEdit from source. I simply installed it through Cygwin. Can you offer any suggestions to deal with this problem? Regards,Akshay Hmm, it's probably a keyboard error then, are you using a funky keyboard? What version of xkeyboard-config do you have? You'll want to make sure it's the most recent version, from February 2018: https://cygwin.com/packages/x86_64/xkeyboard-config/ https://freedesktop.org/wiki/Software/XKeyboardConfig/ ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xorg Digest, Vol 163, Issue 8
Message: 1 Date: Mon, 11 Feb 2019 18:14:27 + (UTC) From: akshay chavan To: "xorg@lists.x.org" Subject: Problems using an X-Window application on Cygwin Message-ID: <844242032.1743315.1549908867...@mail.yahoo.com> Content-Type: text/plain; charset="utf-8" Hi, I have installed a X-Window text editor called NEdit 5.6 on Windows 10 using Cygwin. I have installed all the required X packages such as xorg-server, xinit, etc required to run X-Window applications I have noticed that whenever I open ANY dialog, such as "Goto line number", "save as" or "open", the keyboard input does NOT show in the dialog's textbox. For instance, if I open the "goto line number" dialog, and type something, the entered number does not show up in the dialog's textbox . Similarly, when I open the "save as" dialog, I CANNOT type in the "Directory" field. These problems are NOT observed when I press and hold the middle mouse click on the textbox. As long as I hold the middle mouse click, the textbox shows the characters typed in. When I release the mouse click, I can no longer enter anything in the textbox. Is this issue related to xinit? I tried searching online for a solution but didn't find anything. Thanks, Akshay That's probably a Motif problem not an Nedit problem, what version of Motif is your Cygwin using? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: When starting Evolution /usr/lib/gdm3/gdm-x-session[2309]: (II) modeset information is printed to syslog
On Mon, 2018-09-24 at 19:46 -0500, Chris Pollock wrote: > On Thu, 2018-09-06 at 10:10 -0500, Chris wrote: > > On Thu, 2018-09-06 at 16:00 +0200, Michel Dänzer wrote: > > > On 2018-09-06 1:53 p.m., Chris wrote: > > > > On Thu, 2018-09-06 at 12:21 +0200, Michel Dänzer wrote: > > > > > On 2018-09-05 9:16 p.m., Adam Jackson wrote: > > > > > > On Sat, 2018-09-01 at 10:24 -0500, Chris wrote: > > > > > > > > > > > > > When starting Evolution this is output to syslog and > > > > > > > periodically > > > > > > > after it's running: > > > > > > > > > > > > > > https://pastebin.com/zndBukUG > > > > > > > > > > > > Evolution, or something it provokes, is asking the server > > > > > > for > > > > > > the > > > > > > list > > > > > > of available video modes. It's doing so with > > > > > > XRRGetScreenResources(), > > > > > > apparently, which prompts the X server to go re-check every > > > > > > available > > > > > > output to see if anything has changed. This is silly, it > > > > > > should > > > > > > be > > > > > > using XRRGetScreenResourcesCurrent() and relying on hotplug > > > > > > events > > > > > > to > > > > > > trigger re-polling. Now, maybe the X server shouldn't print > > > > > > the > > > > > > modes > > > > > > in the log when that happens, [...] > > > > > > > > > > FWIW, it probably shouldn't indeed, at least not at the > > > > > default > > > > > log > > > > > verbosity. > > > > > > > > > > > > > AFAICT my rsyslog.conf it's the default. I don't know if > > > > uncommenting > > > > these lines would help or not: > > > > > > > > ### Debugging ### > > > > # $DebugFile /var/log/rsyslog-debug > > > > # $DebugLevel 2 > > > > > > > > # syslog.* /var/log/syslog.debug;RSYSLOG_DebugFormat > > > > # $DebugFile /var/log/syslog.debug > > > > # $DebugLevel 2 > > > > > > Yeah, sorry, different meaning of "should" — the code definitely > > > always > > > has printed these by default, it just arguably shouldn't. > > > > > > Anyway, Adam is right that the client shouldn't use this > > > functionality > > > in the first place. > > > > > > > Besides the bug report submitted at Ubuntu Launchpad that I > > mentioned > > in my original post I've also submitted them as noted below. > > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1788739 > > > > https://bugs.freedesktop.org/show_bug.cgi?id=107841 > > > > https://gitlab.gnome.org/GNOME/gdm/issues/418 > > > > The reasoning for this is I'm just not exactly who's purview this > > would > > come under. > > > > I thought I'd add that this also happens when starting and stopping > XFE > > xfe: > Installed: 1.42-1 > Candidate: 1.42-1 > Thought I'd post an update to this since I've tried several different things to try and stop the output to syslog. Firstly I recognize that this is on information (II) however I don't believe it should be written to my syslog ever time I open or close certain applications. Per suggestions on the Ubuntu-Users list I first installed a new VGA cable, no change. Since my Dell Optiplex 780 has a DisplayPort output connector and my ACER monitor has a DVI input port. I bought and installed a DisplayPort->DVI cable. Here is the ~/.local/share/xorg/Xorg.1.log as written after I installed the cable and booted the system last Friday and output to it through today https://pastebin.com/FjfYcUS1 I don't know if there's any information there that would give a clue as to what's the cause or not. I believe the major issue in troubleshooting this is that it will not happen each time I start or stop Evo, XFE, Firefox or others that seems to cause it. -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 15:27:03 up 3 days, 52 min, 1 user, load average: 0.99, 0.58, 0.65 Description:Ubuntu 18.04.1 LTS, kernel 4.15.0-39-generic signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: X freezes for a second or every now and then when lid closed
Quoting Joel Fernandes (2018-10-27 09:14:07) > On Sat, Oct 27, 2018 at 12:38:56AM -0700, Joel Fernandes wrote: > > Hi! > > My Linux laptop running kernel v4.17 freezes intermittently when the laptop > > lid is closed but external monitors are connected to 2 HDMI ports. I > > provided > > details on the issue, any idea what could be causing it? > > > > I ruled out many different subsystems by trial and error, finally I enabled > > ftrace events on power subsystem and see that the freeze is precisely at the > > same time as drm_mode_getconnector is called on these events and its the > > Xorg > > process. I think since Xorg is busy on this drm_mode_getconnector ioctl, its > > not able to perform its duties. > > > > I get a stacktrace like so: > > Xorg-1285 [001] 801.156606: pm_qos_update_request: > >pm_qos_class=CPU_DMA_LATENCY value=-1 > > Xorg-1285 [001] 801.156607: pm_qos_update_target: > >action=UPDATE_REQ prev_value=0 curr_value=20 > > Xorg-1285 [001] 801.156609: > > => pm_qos_update_target > > => intel_dp_aux_xfer > > => intel_dp_aux_transfer > > => drm_dp_dpcd_access > > => drm_dp_dpcd_read > > => intel_dp_read_dpcd > > => intel_dp_detect > > => drm_helper_probe_single_connector_modes > > => drm_mode_getconnector > > => drm_ioctl_kernel > > => drm_ioctl > > => do_vfs_ioctl > > => ksys_ioctl > > => __x64_sys_ioctl > > => do_syscall_64 > > => entry_SYSCALL_64_after_hwframe > > > > The X version I'm running is X.Org X Server 1.19.6 > > > > I also see these in /var/log/Xorg.0.log every 30 seconds and it seems > > correlated to the time of freezing: > > [ 1141.925] (--) modeset(0): HDMI max TMDS frequency 17KHz > > [ 1142.223] (II) modeset(0): EDID vendor "HWP", prod id 13093 > > [ 1142.223] (II) modeset(0): Using hsync ranges from config file > > [ 1142.223] (II) modeset(0): Using vrefresh ranges from config file > > [ 1142.223] (II) modeset(0): Printing DDC gathered Modelines: > > [ 1142.223] (II) modeset(0): Modeline "1920x1080"x0.0 148.50 1920 2008 > > 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP) > > [ 1142.223] (II) modeset(0): Modeline "1920x1080"x0.0 148.50 1920 2448 > > 2492 2640 1080 1084 1089 1125 +hsync +vsync (56.2 kHz e) > > > > Let me know if you spot anything weird, and if you have any suggestions? > > Just for documenting it, the issue seems very similar to what is reported in > this comment: > https://forums.linuxmint.com/viewtopic.php?t=253475#p1457587 > > I am indeed using Cinammon as well. With the lid closed, the same 'modeset' > log messages appear and freeze the system every 30 seconds. 30s == hotplug polling kthread; the implication would be that it is generating a hotplug uevent everytime. drm.debug=0xe should record what it going on, so capture a dmesg with the lid closed. Platform and panel HW would be useful to know, dmesg from boot is usually sufficient. -Chris ___ 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: When starting Evolution /usr/lib/gdm3/gdm-x-session[2309]: (II) modeset information is printed to syslog
On Thu, 2018-09-06 at 10:10 -0500, Chris wrote: > On Thu, 2018-09-06 at 16:00 +0200, Michel Dänzer wrote: > > On 2018-09-06 1:53 p.m., Chris wrote: > > > On Thu, 2018-09-06 at 12:21 +0200, Michel Dänzer wrote: > > > > On 2018-09-05 9:16 p.m., Adam Jackson wrote: > > > > > On Sat, 2018-09-01 at 10:24 -0500, Chris wrote: > > > > > > > > > > > When starting Evolution this is output to syslog and > > > > > > periodically > > > > > > after it's running: > > > > > > > > > > > > https://pastebin.com/zndBukUG > > > > > > > > > > Evolution, or something it provokes, is asking the server for > > > > > the > > > > > list > > > > > of available video modes. It's doing so with > > > > > XRRGetScreenResources(), > > > > > apparently, which prompts the X server to go re-check every > > > > > available > > > > > output to see if anything has changed. This is silly, it > > > > > should > > > > > be > > > > > using XRRGetScreenResourcesCurrent() and relying on hotplug > > > > > events > > > > > to > > > > > trigger re-polling. Now, maybe the X server shouldn't print > > > > > the > > > > > modes > > > > > in the log when that happens, [...] > > > > > > > > FWIW, it probably shouldn't indeed, at least not at the default > > > > log > > > > verbosity. > > > > > > > > > > AFAICT my rsyslog.conf it's the default. I don't know if > > > uncommenting > > > these lines would help or not: > > > > > > ### Debugging ### > > > # $DebugFile /var/log/rsyslog-debug > > > # $DebugLevel 2 > > > > > > # syslog.* /var/log/syslog.debug;RSYSLOG_DebugFormat > > > # $DebugFile /var/log/syslog.debug > > > # $DebugLevel 2 > > > > Yeah, sorry, different meaning of "should" — the code definitely > > always > > has printed these by default, it just arguably shouldn't. > > > > Anyway, Adam is right that the client shouldn't use this > > functionality > > in the first place. > > > > Besides the bug report submitted at Ubuntu Launchpad that I mentioned > in my original post I've also submitted them as noted below. > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1788739 > > https://bugs.freedesktop.org/show_bug.cgi?id=107841 > > https://gitlab.gnome.org/GNOME/gdm/issues/418 > > The reasoning for this is I'm just not exactly who's purview this > would > come under. > I thought I'd add that this also happens when starting and stopping XFE xfe: Installed: 1.42-1 Candidate: 1.42-1 -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 19:44:42 up 13:06, 1 user, load average: 0.58, 0.49, 0.54 Description:Ubuntu 18.04.1 LTS, kernel 4.15.0-34-generic signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: One (Intel) GPU multiseat without Xephyr/Xnest, with a Xorg server per output
Quoting Troll Berserker (2018-09-18 16:28:02) > Is it possible? man 4 intel, search for ZaphodHeads -Chris ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: When starting Evolution /usr/lib/gdm3/gdm-x-session[2309]: (II) modeset information is printed to syslog
On Thu, 2018-09-06 at 12:21 +0200, Michel Dänzer wrote: > On 2018-09-05 9:16 p.m., Adam Jackson wrote: > > On Sat, 2018-09-01 at 10:24 -0500, Chris wrote: > > > > > When starting Evolution this is output to syslog and periodically > > > after it's running: > > > > > > https://pastebin.com/zndBukUG > > > > Evolution, or something it provokes, is asking the server for the > > list > > of available video modes. It's doing so with > > XRRGetScreenResources(), > > apparently, which prompts the X server to go re-check every > > available > > output to see if anything has changed. This is silly, it should be > > using XRRGetScreenResourcesCurrent() and relying on hotplug events > > to > > trigger re-polling. Now, maybe the X server shouldn't print the > > modes > > in the log when that happens, [...] > > FWIW, it probably shouldn't indeed, at least not at the default log > verbosity. > AFAICT my rsyslog.conf it's the default. I don't know if uncommenting these lines would help or not: ### Debugging ### # $DebugFile /var/log/rsyslog-debug # $DebugLevel 2 # syslog.* /var/log/syslog.debug;RSYSLOG_DebugFormat # $DebugFile /var/log/syslog.debug # $DebugLevel 2 -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 06:49:25 up 5 days, 20:07, 1 user, load average: 0.69, 0.53, 0.49 Description:Ubuntu 18.04.1 LTS, kernel 4.15.0-33-generic signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: When starting Evolution /usr/lib/gdm3/gdm-x-session[2309]: (II) modeset information is printed to syslog
On Wed, 2018-09-05 at 15:16 -0400, Adam Jackson wrote: > On Sat, 2018-09-01 at 10:24 -0500, Chris wrote: > > > When starting Evolution this is output to syslog and periodically > > after it's running: > > > > https://pastebin.com/zndBukUG > > Evolution, or something it provokes, is asking the server for the > list > of available video modes. It's doing so with XRRGetScreenResources(), > apparently, which prompts the X server to go re-check every available > output to see if anything has changed. This is silly, it should be > using XRRGetScreenResourcesCurrent() and relying on hotplug events to > trigger re-polling. Now, maybe the X server shouldn't print the modes > in the log when that happens, but maybe the client shouldn't be ten > years behind the times in its API usage. > > In other words, I think this is a gnome bug. > > - ajax > Thanks Adam, I have filed a bug report here - https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1788739 and here https://bugs.freedesktop.org/show_bug.cgi?id=107841 Since the output refers to /usr/lib/gdm3/gdm-x-session I'm going to file a bug report on Gnome Bugzilla under gdm and see how that goes. Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 15:16:34 up 5 days, 4:34, 2 users, load average: 0.71, 1.05, 1.08 Description:Ubuntu 18.04.1 LTS, kernel 4.15.0-33-generic signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
When starting Evolution /usr/lib/gdm3/gdm-x-session[2309]: (II) modeset information is printed to syslog
This started the same day I did the upgrade from 16.04LTS to 18.04LTS. Package/system information below: lsb_release -crid Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic apt-cache policy gdm3 gdm3: Installed: 3.28.2-0ubuntu1.4 Candidate: 3.28.2-0ubuntu1.4 apt-cache policy evolution evolution: Installed: 3.28.1-2 Candidate: 3.28.1-2 apt-cache policy xserver-xorg xserver-xorg: Installed: 1:7.7+19ubuntu7.1 Candidate: 1:7.7+19ubuntu7.1 When starting Evolution this is output to syslog and periodically after it's running: https://pastebin.com/zndBukUG I've filed a bug report on Ubuntu Launchpad: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1788739 Should I also submit a bug report at freedesktop.org for this or is this possibly some kind of a configuration issue that I can check? Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 10:12:57 up 23:30, 1 user, load average: 0.57, 0.44, 0.29 Description:Ubuntu 18.04.1 LTS, kernel 4.15.0-33-generic signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: [PATCH xserver 1/2] xf86-video-modesetting: Add ms_queue_vblank helper
Quoting Keith Packard (2017-09-29 07:20:46)
> This provides an API wrapper around the kernel interface for queueing
> a vblank event, simplifying all of the callers.
>
> Signed-off-by: Keith Packard <kei...@keithp.com>
> ---
> diff --git a/hw/xfree86/drivers/modesetting/dri2.c
> b/hw/xfree86/drivers/modesetting/dri2.c
> index bfaea3b84..b2278e78b 100644
> --- a/hw/xfree86/drivers/modesetting/dri2.c
> +++ b/hw/xfree86/drivers/modesetting/dri2.c
> @@ -747,13 +744,8 @@ ms_dri2_schedule_wait_msc(ClientPtr client, DrawablePtr
> draw, CARD64 target_msc,
>
> if (current_msc >= target_msc)
> target_msc = current_msc;
> -vbl.request.type = (DRM_VBLANK_ABSOLUTE |
> -DRM_VBLANK_EVENT |
> -drmmode_crtc->vblank_pipe);
> -vbl.request.sequence = ms_crtc_msc_to_kernel_msc(crtc, target_msc);
> -vbl.request.signal = (unsigned long)seq;
>
> -ret = drmWaitVBlank(ms->fd, );
> +ret = ms_queue_vblank(crtc, MS_QUEUE_ABSOLUTE, target_msc,
> _msc, seq);
> if (ret) {
> static int limit = 5;
> if (limit) {
Inverted error check.
-Chris
___
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 3/3] os/WaitFor: Use the simpler xorg_list_for_each_entry()
As we are not freeing elements while iterating the list of timers, we
can forgo using the safe variant, and reduce the number of pointer
dances required for the insertion sort.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
os/WaitFor.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/os/WaitFor.c b/os/WaitFor.c
index e3b545b93..ae317dc11 100644
--- a/os/WaitFor.c
+++ b/os/WaitFor.c
@@ -295,7 +295,7 @@ OsTimerPtr
TimerSet(OsTimerPtr timer, int flags, CARD32 millis,
OsTimerCallback func, void *arg)
{
-OsTimerPtr existing, tmp;
+OsTimerPtr existing;
CARD32 now = GetTimeInMillis();
if (!timer) {
@@ -328,7 +328,7 @@ TimerSet(OsTimerPtr timer, int flags, CARD32 millis,
input_lock();
/* Sort into list */
-xorg_list_for_each_entry_safe(existing, tmp, , list)
+xorg_list_for_each_entry(existing, , list)
if ((int) (existing->expires - millis) > 0)
break;
/* This even works at the end of the list -- existing->list will be timers
*/
--
2.17.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/3] os/WaitFor: Use xorg_list_append()
Currently, we use xorg_list_add(new, head->prev) which is functionaly equivalent to xorg_list_append(), but with more pointer chasing, so reduce the strain on the reader and compiler by using the simpler append(). Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> --- os/WaitFor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/os/WaitFor.c b/os/WaitFor.c index 7c7b1d2d4..e3b545b93 100644 --- a/os/WaitFor.c +++ b/os/WaitFor.c @@ -332,7 +332,7 @@ TimerSet(OsTimerPtr timer, int flags, CARD32 millis, if ((int) (existing->expires - millis) > 0) break; /* This even works at the end of the list -- existing->list will be timers */ -xorg_list_add(>list, existing->list.prev); +xorg_list_append(>list, >list); /* Check to see if the timer is ready to run now */ if ((int) (millis - now) <= 0) -- 2.17.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/3] os/WaitFor: Check timers on every iteration
Currently we only check timer expiry if there are no client fd (or other input) waiting to be serviced. This makes it very easy to starve the timers with long request queues, and so miss critical timestamps. The timer subsystem is just another input waiting to be serviced, so evaluate it on every loop like all the others, at the cost of calling GetTimeInMillis() slightly more frequently. (A more invasive and likely OS specific alternative would be to move the timer wheel to the local equivalent of timerfd, and treat it as an input fd to the event loop exactly equivalent to all the others, and so also serviced on every pass. The trade-off being that the kernel timer wheel is likely more efficiently integrated with epoll, but individual updates to each timer would then require syscalls.) Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> --- os/WaitFor.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/os/WaitFor.c b/os/WaitFor.c index fa6a99b18..7c7b1d2d4 100644 --- a/os/WaitFor.c +++ b/os/WaitFor.c @@ -193,10 +193,9 @@ WaitForSomething(Bool are_ready) are_ready = clients_are_ready(); } +timeout = check_timers(); if (are_ready) timeout = 0; -else -timeout = check_timers(); BlockHandler(); if (NewOutputPending) -- 2.17.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: Gradients are broken with glamor when RepeatReflect is set
Quoting Clemens Eisserer (2018-01-23 17:03:04) > Hi, > > Great to see movement regading this issue. > > > It's broken with llvmpipe/softpipe as well. Does it render correctly > > with glamor on i965? If so, maybe it's a Gallium non-driver issue. > > Glamor on Intel Gen5 (Arrendale) procudes results consistent with > radeonsi/llvmpipe. > So it seems the shader is the culprit. Radial shader (which we think is correct): t = abs(fract(t * 0.5 + 0.5) * 2.0 - 1.0); Linear shader (note unnormalized): distance = abs(mod(distance + _pt_distance, 2.0 * _pt_distance) - _pt_distance); Which makes the same mistake as I did in using mod() instead of the GL definition of fract(). Simplest fix will be to normalize distance and then use the correct transformation from the radial shader. -Chris ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Gradients are broken with glamor when RepeatReflect is set
Quoting Chris Wilson (2018-01-23 15:26:50)
> Quoting Jeffrey Smith (2018-01-23 15:15:10)
> > On Mon, Jan 22, 2018 at 3:01 PM, Chris Wilson <ch...@chris-wilson.co.uk>
> > wrote:
> > > Quoting Adam Jackson (2018-01-22 20:09:52)
> > >> On Sat, 2017-12-23 at 19:26 +0100, Clemens Eisserer wrote:
> > >> > Hi there,
> > >> >
> > >> > Glamor's gradient acceleration code is broken in case RepeatReflect is
> > >> > used, please see: https://bugs.freedesktop.org/show_bug.cgi?id=98508
> > >> > I've filed the bug report over a year ago, but except for a
> > >> > confirmation from Michel Dänzer nothing happend.
> > >> >
> > >> > Unfourntunatly I lack the expertise to fix it myself - however instead
> > >> > of leaving it broken forever, could we fall back to software for
> > >> > RepeatReflect.
> > >> > I guess slow is better than completly broken?
> > >>
> > >> Just want to note that this isn't forgotten. I got as far as testing
> > >> the reproducer with Xephyr and verifying glamor was wrong and fb was
> > >> right, but don't yet get what the RepeatReflect math is getting wrong.
> > >> I'll definitely have a fix for 1.20 one way or another, but that may
> > >> just be forcing a fallback.
> > >>
> > >> If anyone wanted to investigate this, I think this is the guilty
> > >> conditional:
> > >>
> > >> https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_gradient.c#n296
> > >
> > > -t = abs(fract(t * 0.5 + 0.5) * 2.0 - 1.0);
> > > +t = abs(fract(abs(t) * 0.5 + 0.5) * 2.0 - 1.0);
> >
> > Chris, where did this definition for fract come from?
>
> Naivety.
>
> > For negative numbers, it does not match the OpenGL definition for
> > fract, which would be
> > #define fract(t) ((t) - floor(t))
> > With fract defined thus, the original transformation of t appears to work
> > fine.
>
> nir also uses the same definition:
> operation("fract", 1, source_types=real_types, c_expression={'f':
> "{src0} - floorf({src0})", 'd': "{src0} - floor({src0})"}),
>
> So maybe it's purely an amdgpu compiler issue? Michel?
static LLVMValueRef emit_ffract(struct ac_llvm_context *ctx,
LLVMValueRef src0)
{
const char *intr = "llvm.floor.f32";
LLVMValueRef fsrc0 = ac_to_float(ctx, src0);
LLVMValueRef params[] = {
fsrc0,
};
LLVMValueRef floor = ac_build_intrinsic(ctx, intr,
ctx->f32, params, 1,
AC_FUNC_ATTR_READNONE);
return LLVMBuildFSub(ctx->builder, fsrc0, floor, "");
}
which looks like it should be correct?
-Chris
___
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: Gradients are broken with glamor when RepeatReflect is set
Quoting Jeffrey Smith (2018-01-23 15:15:10)
> On Mon, Jan 22, 2018 at 3:01 PM, Chris Wilson <ch...@chris-wilson.co.uk>
> wrote:
> > Quoting Adam Jackson (2018-01-22 20:09:52)
> >> On Sat, 2017-12-23 at 19:26 +0100, Clemens Eisserer wrote:
> >> > Hi there,
> >> >
> >> > Glamor's gradient acceleration code is broken in case RepeatReflect is
> >> > used, please see: https://bugs.freedesktop.org/show_bug.cgi?id=98508
> >> > I've filed the bug report over a year ago, but except for a
> >> > confirmation from Michel Dänzer nothing happend.
> >> >
> >> > Unfourntunatly I lack the expertise to fix it myself - however instead
> >> > of leaving it broken forever, could we fall back to software for
> >> > RepeatReflect.
> >> > I guess slow is better than completly broken?
> >>
> >> Just want to note that this isn't forgotten. I got as far as testing
> >> the reproducer with Xephyr and verifying glamor was wrong and fb was
> >> right, but don't yet get what the RepeatReflect math is getting wrong.
> >> I'll definitely have a fix for 1.20 one way or another, but that may
> >> just be forcing a fallback.
> >>
> >> If anyone wanted to investigate this, I think this is the guilty
> >> conditional:
> >>
> >> https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_gradient.c#n296
> >
> > -t = abs(fract(t * 0.5 + 0.5) * 2.0 - 1.0);
> > +t = abs(fract(abs(t) * 0.5 + 0.5) * 2.0 - 1.0);
>
> Chris, where did this definition for fract come from?
Naivety.
> For negative numbers, it does not match the OpenGL definition for
> fract, which would be
> #define fract(t) ((t) - floor(t))
> With fract defined thus, the original transformation of t appears to work
> fine.
nir also uses the same definition:
operation("fract", 1, source_types=real_types, c_expression={'f':
"{src0} - floorf({src0})", 'd': "{src0} - floor({src0})"}),
So maybe it's purely an amdgpu compiler issue? Michel?
-Chris
___
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: Gradients are broken with glamor when RepeatReflect is set
Quoting Adam Jackson (2018-01-22 20:09:52)
> On Sat, 2017-12-23 at 19:26 +0100, Clemens Eisserer wrote:
> > Hi there,
> >
> > Glamor's gradient acceleration code is broken in case RepeatReflect is
> > used, please see: https://bugs.freedesktop.org/show_bug.cgi?id=98508
> > I've filed the bug report over a year ago, but except for a
> > confirmation from Michel Dänzer nothing happend.
> >
> > Unfourntunatly I lack the expertise to fix it myself - however instead
> > of leaving it broken forever, could we fall back to software for
> > RepeatReflect.
> > I guess slow is better than completly broken?
>
> Just want to note that this isn't forgotten. I got as far as testing
> the reproducer with Xephyr and verifying glamor was wrong and fb was
> right, but don't yet get what the RepeatReflect math is getting wrong.
> I'll definitely have a fix for 1.20 one way or another, but that may
> just be forcing a fallback.
>
> If anyone wanted to investigate this, I think this is the guilty
> conditional:
>
> https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_gradient.c#n296
-t = abs(fract(t * 0.5 + 0.5) * 2.0 - 1.0);
+t = abs(fract(abs(t) * 0.5 + 0.5) * 2.0 - 1.0);
#include
#include
#define abs(t) fabs(t)
#define fract(t) fmod((t), 1.0)
static float repeat(float t)
{
return abs(fract(abs(t) * 0.5 + 0.5) * 2.0 - 1.0);
}
int main(void)
{
float t;
for (t = -3; t <= 3; t += .5)
printf("%5.1f ", t);
printf("\n");
for (t = -3; t <= 3; t += .5)
printf("%5.1f ", repeat(t));
printf("\n");
}
-3.0 -2.5 -2.0 -1.5 -1.0 -0.5 0.00.51.01.52.0
2.53.0
1.00.50.00.51.00.50.00.51.00.50.0
0.51.0
-Chris
___
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: [xrandr v2] Select NearestNeighbour filtering for pixel exact scaling
Quoting Matt Turner (2017-09-01 22:17:58)
> Was there a reason this did not land?
It needs a touch more work:
"I was wondering, did you (or anyone else) follow up on this patch? I
recently used it with good success, and would be happy if it was
upstream. Especially as I am planning on getting a 4K monitor soon,
and will likely need to run e.g. games at 1080p resolution.
I did have to add a "continue;" at the end of the
if (!strcmp ("--filter", argv[i])) {
block though, or selecting a filter would not work.
As another note, changing the filter only has an effect if the
resolution/scaling is also altered."
My attempt at doing the latter just ended in segv. After which it just
slipped my mind.
-Chris
___
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] configure.ac: Make BUILD_{DATE, TIME} respect SOURCE_DATE_EPOCH if set
Hi xorg-devel,
Whilst working on the Reproducible Builds effort [0], we noticed
that xorg-server could not be built reproducibly.
One reason is because it embeds a build and date time. Patch
attached.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb, Debian Project Leader
`. `'` la...@debian.org / chris-lamb.co.uk
`-
From bb171c65af6ee0c8b48e9108b277b1f9ff21f978 Mon Sep 17 00:00:00 2001
From: Chris Lamb <ch...@chris-lamb.co.uk>
Date: Thu, 20 Jul 2017 15:42:15 +0100
Subject: [PATCH] configure.ac: Make BUILD_{DATE,TIME} respect
SOURCE_DATE_EPOCH if set
Whilst working on the Reproducible Builds effort [0], we noticed that
xorg-server could not be built reproducibly. One reason is because it
embeds a "current" build and date time.
This should be compatible with both GNU and BSD date(1).
[0] https://reproducible-builds.org/
---
configure.ac | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e202770c1..f10a94cb4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2405,9 +2405,15 @@ AC_DEFINE_DIR(PROJECTROOT, prefix, [Overall prefix])
AC_DEFINE_DIR(SYSCONFDIR, sysconfdir, [sysconfdir])
AC_SUBST([RELEASE_DATE])
-BUILD_DATE="`date +'%Y%m%d'`"
+DATE_FMT="%Y-%m-%d"
+TIME_FMT="1%H%M%S"
+BUILD_DATE="`date "+$DATE_FMT"`"
+BUILD_TIME="`date "+$TIME_FMT"`"
+if test "x$SOURCE_DATE_EPOCH" != "x"; then
+ BUILD_DATE="`date -u -d "@$SOURCE_DATE_EPOCH" "+$DATE_FMT" 2>/dev/null || date -u -r "$SOURCE_DATE_EPOCH" "+$DATE_FMT" 2>/dev/null || date -u "+$DATE_FMT"`"
+ BUILD_TIME="`date -u -d "@$SOURCE_DATE_EPOCH" "+$TIME_FMT" 2>/dev/null || date -u -r "$SOURCE_DATE_EPOCH" "+$TIME_FMT" 2>/dev/null || date -u "+$TIME_FMT"`"
+fi
AC_SUBST([BUILD_DATE])
-BUILD_TIME="`date +'1%H%M%S'`"
AC_SUBST([BUILD_TIME])
DIX_CFLAGS="-DHAVE_DIX_CONFIG_H $XSERVER_CFLAGS"
--
2.13.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Intel-gfx] intel driver 4k MST
On Mon, Mar 27, 2017 at 04:47:44PM +0200, René Rebe wrote: > Hi all, > > connecting a Dell 4k MST display using the xorg intel driver on two different > machines (Surface Pro 3, Dell XPS 13 9360) results in one of the two halts > mirrored on the two MST halfs of the display. Using xrandr --left-of / > --right-of I could not yet find a combination that would correctly show the > whole screen. > > In contrast using the xorg modesetting driver on the same kernel and > xorg-server 4k MST works out of the box. > > Is this a know limitation or the intel xorg driver that is just considered > obsolete and dead or anything? It is not likely a ddx bug... -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: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] Revert "prime: Sync shared pixmap from root window instead of screen pixmap"
This reverts commit b5b292896f647c85f03f53b20b2f03c0e94de428.
This breaks the concept of the screen->pixmap_dirty_list as it no longer
tracks the relationship between the PixmapDirtyUpdate src and slave_dst,
for the supposed convenience of not tracking present flips.
---
dix/pixmap.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/dix/pixmap.c b/dix/pixmap.c
index b67a2e8a6..7a6402411 100644
--- a/dix/pixmap.c
+++ b/dix/pixmap.c
@@ -241,8 +241,7 @@ PixmapStartDirtyTracking(PixmapPtr src,
RegionUnion(damageregion, damageregion, );
RegionUninit();
-DamageRegister(screen->root ? >root->drawable : >drawable,
- dirty_update->damage);
+DamageRegister(>drawable, dirty_update->damage);
xorg_list_add(_update->ent, >pixmap_dirty_list);
return TRUE;
}
@@ -270,7 +269,6 @@ PixmapDirtyCopyArea(PixmapPtr dst,
RegionPtr dirty_region)
{
ScreenPtr pScreen = dirty->src->drawable.pScreen;
-DrawablePtr src = pScreen->root ? >root->drawable :
>src->drawable;
int n;
BoxPtr b;
GCPtr pGC;
@@ -278,13 +276,7 @@ PixmapDirtyCopyArea(PixmapPtr dst,
n = RegionNumRects(dirty_region);
b = RegionRects(dirty_region);
-pGC = GetScratchGC(src->depth, pScreen);
-if (pScreen->root) {
-ChangeGCVal subWindowMode;
-
-subWindowMode.val = IncludeInferiors;
-ChangeGC(NullClient, pGC, GCSubwindowMode, );
-}
+pGC = GetScratchGC(dirty->src->drawable.depth, pScreen);
ValidateGC(>drawable, pGC);
while (n--) {
@@ -295,7 +287,7 @@ PixmapDirtyCopyArea(PixmapPtr dst,
w = dst_box.x2 - dst_box.x1;
h = dst_box.y2 - dst_box.y1;
-pGC->ops->CopyArea(src, >drawable, pGC,
+pGC->ops->CopyArea(>src->drawable, >drawable, pGC,
dirty->x + dst_box.x1, dirty->y + dst_box.y1, w, h,
dirty->dst_x + dst_box.x1,
dirty->dst_y + dst_box.y1);
@@ -318,7 +310,7 @@ PixmapDirtyCompositeRotate(PixmapPtr dst_pixmap,
int error;
src = CreatePicture(None,
->root->drawable,
+>src->drawable,
format,
CPSubwindowMode,
_inferiors, serverClient, );
--
2.11.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] inputthread: Initialise inputThreadInfo->changed before use
==8734== Thread 2 InputThread:
==8734== Conditional jump or move depends on uninitialised value(s)
==8734==at 0x2FDB05: InputThreadDoWork (inputthread.c:333)
==8734==by 0x6924423: start_thread (pthread_create.c:333)
==8734==by 0x6C229BE: clone (clone.S:105)
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
os/inputthread.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/os/inputthread.c b/os/inputthread.c
index 8e7f2edb9..4400fba3f 100644
--- a/os/inputthread.c
+++ b/os/inputthread.c
@@ -403,6 +403,8 @@ InputThreadPreInit(void)
if (!inputThreadInfo)
FatalError("input-thread: could not allocate memory");
+inputThreadInfo->changed = FALSE;
+
inputThreadInfo->thread = 0;
xorg_list_init(>devs);
inputThreadInfo->fds = ospoll_create();
--
2.11.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] os: Fix iteration over busfaults
Fixes a regression from
commit 41da295eb50fa08eaacd0ecde99f43a716fcb41a
Author: Keith Packard <kei...@keithp.com>
Date: Sun Nov 3 13:12:40 2013 -0800
Trap SIGBUS to handle truncated shared memory segments
that causes the SIGBUS handler to fail to chain up correctly and
corrupts nearby memory instead.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
os/busfault.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/os/busfault.c b/os/busfault.c
index d4afa6df3..a2d433a2e 100644
--- a/os/busfault.c
+++ b/os/busfault.c
@@ -98,15 +98,16 @@ static void
busfault_sigaction(int sig, siginfo_t *info, void *param)
{
void*fault = info->si_addr;
-struct busfault *busfault = NULL;
+struct busfault *iter, *busfault = NULL;
void*new_addr;
/* Locate the faulting address in our list of shared segments
*/
-xorg_list_for_each_entry(busfault, , list) {
-if ((char *) busfault->addr <= (char *) fault && (char *) fault <
(char *) busfault->addr + busfault->size) {
-break;
-}
+xorg_list_for_each_entry(iter, , list) {
+ if ((char *) iter->addr <= (char *) fault && (char *) fault < (char *)
iter->addr + iter->size) {
+ busfault = iter;
+ break;
+ }
}
if (!busfault)
goto panic;
@@ -132,7 +133,7 @@ panic:
if (previous_busfault_sigaction)
(*previous_busfault_sigaction)(sig, info, param);
else
-FatalError("bus error");
+FatalError("bus error\n");
}
Bool
--
2.11.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/3] xfree86: Take input lock for xf86TransparentCursor
The new input lock is missing for the xf86TransparentCursor() entry
point.
Fixes: 6a5a4e60373c ("Remove SIGIO support for input [v5]")
References: https://bugs.freedesktop.org/show_bug.cgi?id=99358
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
hw/xfree86/ramdac/xf86HWCurs.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c
index 55d5861c1..26dc7e5af 100644
--- a/hw/xfree86/ramdac/xf86HWCurs.c
+++ b/hw/xfree86/ramdac/xf86HWCurs.c
@@ -261,6 +261,8 @@ xf86SetTransparentCursor(ScreenPtr pScreen)
xf86CursorScreenKey);
xf86CursorInfoPtr infoPtr = ScreenPriv->CursorInfoPtr;
+input_lock();
+
if (!ScreenPriv->transparentData)
ScreenPriv->transparentData =
(*infoPtr->RealizeCursor) (infoPtr, NullCursor);
@@ -273,6 +275,8 @@ xf86SetTransparentCursor(ScreenPtr pScreen)
ScreenPriv->transparentData);
(*infoPtr->ShowCursor) (infoPtr->pScrn);
+
+input_unlock();
}
static void
--
2.11.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 3/3] xfree86: Take input_lock() for xf86ScreenCheckHWCursor
Add the missing input_lock() around the call into the driver's
UseHWCursor() callback.
Fixes: 6a5a4e60373c ("Remove SIGIO support for input [v5]")
References: https://bugs.freedesktop.org/show_bug.cgi?id=99358
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
hw/xfree86/ramdac/xf86HWCurs.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c
index 26dc7e5af..09d59b15d 100644
--- a/hw/xfree86/ramdac/xf86HWCurs.c
+++ b/hw/xfree86/ramdac/xf86HWCurs.c
@@ -139,9 +139,14 @@ Bool
xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, xf86CursorInfoPtr
infoPtr)
{
ScreenPtr pSlave;
+Bool use_hw_cursor = TRUE;
-if (!xf86ScreenCheckHWCursor(pScreen, cursor, infoPtr))
-return FALSE;
+input_lock();
+
+if (!xf86ScreenCheckHWCursor(pScreen, cursor, infoPtr)) {
+use_hw_cursor = FALSE;
+goto unlock;
+}
/* ask each driver consuming a pixmap if it can support HW cursor */
xorg_list_for_each_entry(pSlave, >slave_list, slave_head) {
@@ -151,14 +156,22 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor,
xf86CursorInfoPtr infoPtr
continue;
sPriv = dixLookupPrivate(>devPrivates, xf86CursorScreenKey);
-if (!sPriv) /* NULL if Option "SWCursor", possibly other conditions */
-return FALSE;
+if (!sPriv) { /* NULL if Option "SWCursor", possibly other conditions
*/
+use_hw_cursor = FALSE;
+break;
+}
/* FALSE if HWCursor not supported by slave */
-if (!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr))
-return FALSE;
+if (!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr)) {
+use_hw_cursor = FALSE;
+break;
+}
}
-return TRUE;
+
+unlock:
+input_unlock();
+
+return use_hw_cursor;
}
static Bool
--
2.11.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/3] xfree86: Take the input lock for xf86RecolorCursor
xf86RecolorCursor() may be called directly from XRecolorCursor as well
as from xf86ScreenSetCursor(). In the latter case, the input lock is
already held, but not for the former and so we need to add a wrapper
function that acquires the input lock before performing
xf86RecolorCursor()
Fixes: 6a5a4e60373c ("Remove SIGIO support for input [v5]")
References: https://bugs.freedesktop.org/show_bug.cgi?id=99358
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
hw/xfree86/ramdac/xf86HWCurs.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c
index 448132095..55d5861c1 100644
--- a/hw/xfree86/ramdac/xf86HWCurs.c
+++ b/hw/xfree86/ramdac/xf86HWCurs.c
@@ -22,6 +22,9 @@
#include "servermd.h"
+static void
+xf86RecolorCursor_locked(xf86CursorScreenPtr ScreenPriv, CursorPtr pCurs);
+
static CARD32
xf86ReverseBitOrder(CARD32 v)
{
@@ -204,7 +207,7 @@ xf86ScreenSetCursor(ScreenPtr pScreen, CursorPtr pCurs, int
x, int y)
if (!xf86DriverLoadCursorImage (infoPtr, bits))
return FALSE;
-xf86RecolorCursor(pScreen, pCurs, 1);
+xf86RecolorCursor_locked (ScreenPriv, pCurs);
(*infoPtr->SetCursorPosition) (infoPtr->pScrn, x, y);
@@ -312,12 +315,9 @@ xf86MoveCursor(ScreenPtr pScreen, int x, int y)
input_unlock();
}
-void
-xf86RecolorCursor(ScreenPtr pScreen, CursorPtr pCurs, Bool displayed)
+static void
+xf86RecolorCursor_locked(xf86CursorScreenPtr ScreenPriv, CursorPtr pCurs)
{
-xf86CursorScreenPtr ScreenPriv =
-(xf86CursorScreenPtr) dixLookupPrivate(>devPrivates,
- xf86CursorScreenKey);
xf86CursorInfoPtr infoPtr = ScreenPriv->CursorInfoPtr;
/* recoloring isn't applicable to ARGB cursors and drivers
@@ -357,6 +357,18 @@ xf86RecolorCursor(ScreenPtr pScreen, CursorPtr pCurs, Bool
displayed)
}
}
+void
+xf86RecolorCursor(ScreenPtr pScreen, CursorPtr pCurs, Bool displayed)
+{
+xf86CursorScreenPtr ScreenPriv =
+(xf86CursorScreenPtr) dixLookupPrivate(>devPrivates,
+ xf86CursorScreenKey);
+
+input_lock();
+xf86RecolorCursor_locked (ScreenPriv, pCurs);
+input_unlock();
+}
+
/* These functions assume that MaxWidth is a multiple of 32 */
static unsigned char *
RealizeCursorInterleave0(xf86CursorInfoPtr infoPtr, CursorPtr pCurs)
--
2.11.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] xfree86: Choose the largest output as primary for xf86TargetFallback()
With all things equal (i.e. same output preferences), use the largest
output as the primary. From the primary, we choose compatible modes for
the others, and given that we are configuring an extended desktop, we
have greater freedom in our selection and may as well base our choice on
the largest mode available.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
hw/xfree86/modes/xf86Crtc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 966a168..048c3b2 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -2413,7 +2413,10 @@ xf86TargetFallback(ScrnInfoPtr scrn, xf86CrtcConfigPtr
config,
default_preferred = (((default_mode->type & M_T_PREFERRED) != 0) +
((default_mode->type & M_T_USERPREF) != 0));
-if (default_preferred > target_preferred || !target_mode) {
+if (!target_mode ||
+default_preferred > target_preferred ||
+(default_preferred == target_preferred &&
+ biggestMode(default_mode, target_mode))) {
target_mode = default_mode;
target_preferred = default_preferred;
target_rotation = config->output[o]->initial_rotation;
--
2.9.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v6 10/11] modesetting: Disable Reverse PRIME for i915
On Sun, Jun 12, 2016 at 06:23:25PM +0100, Emil Velikov wrote:
> On 12 June 2016 at 17:09, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> > On Sun, Jun 12, 2016 at 02:35:43PM +0100, Emil Velikov wrote:
> >> Hi all,
> >>
> >> On 11 June 2016 at 01:21, Alex Goins <ago...@nvidia.com> wrote:
> >> > Reverse PRIME seems to be designed with discrete graphics as a sink in
> >> > mind, designed to do an extra copy from sysmem to vidmem to prevent a
> >> > discrete chip from needing to scan out from sysmem.
> >> >
> >> > The criteria it used to detect this case is if we are a GPU screen and
> >> > Glamor accelerated. It's possible for i915 to fulfill these conditions,
> >> > despite the fact that the additional copy doesn't make sense for i915.
> >> >
> >> > Normally, you could just set AccelMethod = none as an option for the
> >> > device
> >> > and call it a day. However, when running with modesetting as both the
> >> > sink
> >> > and the source, Glamor must be enabled.
> >> >
> >> > Ideally, you would be able to set AccelMethod individually for devices
> >> > using the same driver, but there seems to be a bug in X option parsing
> >> > that
> >> > makes all devices on a driver inherit the options from the first detected
> >> > device. Thus, glamor needs to be enabled for all or for none until that
> >> > bug
> >> > (if it's even a bug) is fixed.
> >> >
> >> > Nonetheless, it probably doesn't make sense to do the extra copy on i915
> >> > even if Glamor is enabled for the device, so this is more user friendly
> >> > by
> >> > not requiring users to disable acceleration for i915.
> >> >
> >> IMHO the proposed patch does not sound like a reasonable long-term
> >> solution. Ideally the driver will expose a flag, based on which Xorg
> >> will enable/disable reverse prime. That said, as a short-term fix this
> >> is fine, barring the issues mentioned below.
> >
> > The decision as to whether or not the slave can use the passed pixmap as
> > its own scanout (or whether it requires a copy) is not part of the
> > master's policy.
> Hi Chris, it's this precisely what I've said/meant :-)
>
> To put in other words:
> IMHO the master/slave device should expose all their capabilities.
> Based on these, Xorg should {en,dis}able reverse prime/etc.
Yes. But I would prefer it if the user made the choice, it may require
to jump through 20 different hoops, but if it is the only way to achieve
the user's configuration, that is what is need to be done.
This patch seems to be second guessing what the slave might be doing
instead, as you said, exposing a method by which the master/slave can
negotiate on what is being passed between them.
-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: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v6 10/11] modesetting: Disable Reverse PRIME for i915
On Sun, Jun 12, 2016 at 02:35:43PM +0100, Emil Velikov wrote: > Hi all, > > On 11 June 2016 at 01:21, Alex Goins <ago...@nvidia.com> wrote: > > Reverse PRIME seems to be designed with discrete graphics as a sink in > > mind, designed to do an extra copy from sysmem to vidmem to prevent a > > discrete chip from needing to scan out from sysmem. > > > > The criteria it used to detect this case is if we are a GPU screen and > > Glamor accelerated. It's possible for i915 to fulfill these conditions, > > despite the fact that the additional copy doesn't make sense for i915. > > > > Normally, you could just set AccelMethod = none as an option for the device > > and call it a day. However, when running with modesetting as both the sink > > and the source, Glamor must be enabled. > > > > Ideally, you would be able to set AccelMethod individually for devices > > using the same driver, but there seems to be a bug in X option parsing that > > makes all devices on a driver inherit the options from the first detected > > device. Thus, glamor needs to be enabled for all or for none until that bug > > (if it's even a bug) is fixed. > > > > Nonetheless, it probably doesn't make sense to do the extra copy on i915 > > even if Glamor is enabled for the device, so this is more user friendly by > > not requiring users to disable acceleration for i915. > > > IMHO the proposed patch does not sound like a reasonable long-term > solution. Ideally the driver will expose a flag, based on which Xorg > will enable/disable reverse prime. That said, as a short-term fix this > is fine, barring the issues mentioned below. The decision as to whether or not the slave can use the passed pixmap as its own scanout (or whether it requires a copy) is not part of the master's policy. -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: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] uxa: fix missing includes for fstat
On Tue, Apr 26, 2016 at 02:42:52PM +0200, Stefan Dirsch wrote: > From: Dominique Leuenberger <dims...@opensuse.org> > > Without these headers, we can run into build errors like: sys/stat.h is already included. Curious. -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: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] present: Be consistent in using window vs vblank->window in present_execute()
Upon entering the function, we copy frequently accessed members of the
vblank structure to locals (such as the Window). However, we then
fluctuate between using the local window and the vblank->window. Under
certain situations, the present_flip callback into the driver may be
completed instantaneously and so accessing the vblank structure after a
successful call into the driver may cause a use-after-free. This is
trivially avoided by using the locals we took earlier.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
present/present.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/present/present.c b/present/present.c
index 105e2bf..a90f08d 100644
--- a/present/present.c
+++ b/present/present.c
@@ -628,6 +628,7 @@ present_execute(present_vblank_ptr vblank, uint64_t ust,
uint64_t crtc_msc)
{
WindowPtr window = vblank->window;
ScreenPtr screen = window->drawable.pScreen;
+PixmapPtr pixmap = vblank->pixmap;
present_screen_priv_ptr screen_priv = present_screen_priv(screen);
uint8_t mode;
@@ -648,7 +649,7 @@ present_execute(present_vblank_ptr vblank, uint64_t ust,
uint64_t crtc_msc)
}
}
-if (vblank->flip && vblank->pixmap && vblank->window) {
+if (vblank->flip && pixmap && window) {
if (screen_priv->flip_pending || screen_priv->unflip_event_id) {
DebugPresent(("\tr %lld %p (pending %p unflip %lld)\n",
vblank->event_id, vblank,
@@ -662,13 +663,14 @@ present_execute(present_vblank_ptr vblank, uint64_t ust,
uint64_t crtc_msc)
xorg_list_del(>window_list);
vblank->queued = FALSE;
-if (vblank->pixmap && vblank->window) {
+if (pixmap && window) {
if (vblank->flip) {
+ RegionPtr damage = vblank->update;
DebugPresent(("\tf %lld %p %8lld: %08lx -> %08lx\n",
vblank->event_id, vblank, crtc_msc,
- vblank->pixmap->drawable.id,
vblank->window->drawable.id));
+ id, window->drawable.id));
/* Prepare to flip by placing it in the flip queue and
* and sticking it into the flip_pending field
@@ -678,8 +680,7 @@ present_execute(present_vblank_ptr vblank, uint64_t ust,
uint64_t crtc_msc)
xorg_list_add(>event_queue, _flip_queue);
/* Try to flip
*/
-if (present_flip(vblank->crtc, vblank->event_id,
vblank->target_msc, vblank->pixmap, vblank->sync_flip)) {
-RegionPtr damage;
+if (present_flip(vblank->crtc, vblank->event_id,
vblank->target_msc, pixmap, vblank->sync_flip)) {
/* Fix window pixmaps:
* 1) Restore previous flip window pixmap
@@ -689,18 +690,17 @@ present_execute(present_vblank_ptr vblank, uint64_t ust,
uint64_t crtc_msc)
present_set_tree_pixmap(screen_priv->flip_window,
screen_priv->flip_pixmap,
(*screen->GetScreenPixmap)(screen));
-present_set_tree_pixmap(vblank->window, NULL, vblank->pixmap);
-present_set_tree_pixmap(screen->root, NULL, vblank->pixmap);
+present_set_tree_pixmap(window, NULL, pixmap);
+present_set_tree_pixmap(screen->root, NULL, pixmap);
/* Report update region as damaged
*/
-if (vblank->update) {
-damage = vblank->update;
+if (damage)
RegionIntersect(damage, damage, >clipList);
-} else
+else
damage = >clipList;
-DamageDamageRegion(>window->drawable, damage);
+DamageDamageRegion(>drawable, damage);
return;
}
@@ -710,7 +710,7 @@ present_execute(present_vblank_ptr vblank, uint64_t ust,
uint64_t crtc_msc)
screen_priv->flip_pending = NULL;
vblank->flip = FALSE;
}
-DebugPresent(("\tc %p %8lld: %08lx -> %08lx\n", vblank, crtc_msc,
vblank->pixmap->drawable.id, vblank->window->drawable.id));
+DebugPresent(("\tc %p %8lld: %08lx -> %08lx\n", vblank, crtc_msc,
pixmap->drawable.id, window->drawable.id));
if (screen_priv->flip_pending) {
/* Check pending flip
@@ -738,7 +738,7 @@ present_execute(present_vblank_ptr vblank, uint64_t ust,
uint64_t crtc_msc)
return;
}
-present_copy_region(>drawable, vblank->pixmap, vblan
[xrandr v2] Select NearestNeighbour filtering for pixel exact scaling
When using pixel-exact scaling from for example running a 3840x2160 monitor
at 1920x1080 half-resolution upscaling using a bilinear filter
introduces blur where none is expected.
v2: Allow the user to specify what filter they want using --filter, but
default to automatic selection.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94816
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
configure.ac | 2 +-
xrandr.c | 275 +--
2 files changed, 192 insertions(+), 85 deletions(-)
diff --git a/configure.ac b/configure.ac
index dcf7c10..95cc1f6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -39,7 +39,7 @@ XORG_DEFAULT_OPTIONS
AC_CHECK_LIB(m,floor)
# Checks for pkg-config packages
-PKG_CHECK_MODULES(XRANDR, xrandr >= 1.5 xrender x11 xproto >= 7.0.17)
+PKG_CHECK_MODULES(XRANDR, xrandr >= 1.5 xrender x11 xproto >= 7.0.17 pixman-1)
AC_CONFIG_FILES([
Makefile
diff --git a/xrandr.c b/xrandr.c
index dcfdde0..5c3a326 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#ifdef HAVE_CONFIG_H
#include "config.h"
@@ -135,6 +136,7 @@ usage(void)
" --scale x\n"
" --scale-from x\n"
" --transform \n"
+ " --filter auto,bilinear,nearest\n"
" --off\n"
" --crtc \n"
" --panning
x[++[/x++[]]]\n"
@@ -285,6 +287,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 {
@@ -305,19 +308,24 @@ typedef struct {
typedef struct _crtc crtc_t;
typedef struct _output output_t;
typedef struct _transform transform_t;
+typedef struct _filter filter_t;
typedef struct _umode umode_t;
typedef struct _output_prop output_prop_t;
typedef struct _provider provider_t;
typedef struct _monitors monitors_t;
typedef struct _umonitor umonitor_t;
-struct _transform {
-XTransform transform;
+struct _filter {
const char *filter;
intnparams;
XFixed *params;
};
+
+struct _transform {
+XTransform transform;
+};
+
struct _crtc {
name_t crtc;
Bool changing;
@@ -331,6 +339,7 @@ struct _crtc {
output_t **outputs;
intnoutput;
transform_tcurrent_transform, pending_transform;
+filter_tcurrent_filter, pending_filter;
};
struct _output_prop {
@@ -370,6 +379,7 @@ struct _output {
Bool automatic;
intscale_from_w, scale_from_h;
transform_ttransform;
+filter_tfilter;
struct {
float red;
@@ -707,19 +717,29 @@ init_transform (transform_t *transform)
memset (>transform, '\0', sizeof (transform->transform));
for (x = 0; x < 3; x++)
transform->transform.matrix[x][x] = XDoubleToFixed (1.0);
-transform->filter = "";
-transform->nparams = 0;
-transform->params = NULL;
+}
+
+static void
+init_filter (filter_t *filter)
+{
+filter->filter = "";
+filter->nparams = 0;
+filter->params = NULL;
}
static void
set_transform (transform_t *dest,
- XTransform *transform,
- const char *filter,
- XFixed *params,
- int nparams)
+ XTransform *transform)
{
dest->transform = *transform;
+}
+
+static void
+set_filter (filter_t*dest,
+ const char *filter,
+ XFixed *params,
+ int nparams)
+{
/* note: this string is leaked */
dest->filter = strdup (filter);
dest->nparams = nparams;
@@ -728,10 +748,25 @@ set_transform (transform_t *dest,
}
static void
+auto_filter (output_t *output)
+{
+if ((output->changes & changes_filter) == 0) {
+init_filter (>filter);
+output->filter.filter = "auto";
+output->changes |= changes_filter;
+}
+}
+
+static void
copy_transform (transform_t *dest, transform_t *src)
{
-set_transform (dest, >transform,
- src->filter, src->params, src->nparams);
+set_transform (dest, >transform);
+}
+
+static void
+copy_filter (filter_t *dest, filter_t *src)
+{
+set_filter(dest, src->filter, src->params, src->nparams);
}
static Bool
@@ -739,6 +774,12 @@ equal_transform (transform_t *a, transform_t *b)
{
if (memcmp (>transform, >transform, sizeof (XTransform)) != 0)
return False;
+return True;
+}
+
+static Bool
+equal_filter (filter_t *a, filter_t *b)
+{
if (strcmp (a->filter, b->fi
Re: [xrandr] Select NearestNeighbour filtering for pixel exact scaling
On Mon, Apr 04, 2016 at 05:11:11PM +0100, Chris Wilson wrote: > When using pixel-exact scaling from for example running a 3840x2160 monitor > at 1920x1080 half-resolution upscaling using a bilinear filter > introduces blur where none is expected. Missed --scale, this only changes --scale-from. -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: https://lists.x.org/mailman/listinfo/xorg-devel
[xrandr] Select NearestNeighbour filtering for pixel exact scaling
When using pixel-exact scaling from for example running a 3840x2160 monitor
at 1920x1080 half-resolution upscaling using a bilinear filter
introduces blur where none is expected.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94816
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
xrandr.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index dcfdde0..b6b208c 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -1292,6 +1292,7 @@ set_output_info (output_t *output, RROutput xid,
XRROutputInfo *output_info)
/* for --scale-from, figure out the mode size and compute the transform
* for the target framebuffer area */
if (output->scale_from_w > 0 && output->mode_info) {
+ XTransform *t = >transform.transform;
double sx = (double)output->scale_from_w /
output->mode_info->width;
double sy = (double)output->scale_from_h /
@@ -1300,10 +1301,10 @@ set_output_info (output_t *output, RROutput xid,
XRROutputInfo *output_info)
printf("scaling %s by %lfx%lf\n", output->output.string, sx,
sy);
init_transform (>transform);
- output->transform.transform.matrix[0][0] = XDoubleToFixed (sx);
- output->transform.transform.matrix[1][1] = XDoubleToFixed (sy);
- output->transform.transform.matrix[2][2] = XDoubleToFixed (1.0);
- if (sx != 1 || sy != 1)
+ t->matrix[0][0] = XDoubleToFixed (sx);
+ t->matrix[1][1] = XDoubleToFixed (sy);
+ t->matrix[2][2] = XDoubleToFixed (1.0);
+ if ((t->matrix[0][0] | t->matrix[1][1]) & 0x)
output->transform.filter = "bilinear";
else
output->transform.filter = "nearest";
--
2.8.0.rc3
___
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] Xext/vidmode: Reduce verbosity of GetModeLine debug messages
In commit f175cf45aebcdda53f3ae49c0eaf27da1f194e92
Author: Olivier Fourdan <ofour...@redhat.com>
Date: Wed Feb 10 09:34:34 2016 +0100
vidmode: move to a separate library of its own
the verbosity of some old debug messages (which print the reply to every
GetModeLine client request and others) was increased leading to lots of
log spam. Downgrade the logging back to DebugF.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94515
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Olivier Fourdan <ofour...@redhat.com>
Cc: Adam Jackson <a...@redhat.com>
---
Xext/vidmode.c | 212 -
1 file changed, 106 insertions(+), 106 deletions(-)
diff --git a/Xext/vidmode.c b/Xext/vidmode.c
index 7c838f4..0cbbdc3 100644
--- a/Xext/vidmode.c
+++ b/Xext/vidmode.c
@@ -69,7 +69,7 @@ typedef struct {
dixSetPrivate(&(c)->devPrivates, VidModeClientPrivateKey, p)
#ifdef DEBUG
-#define DEBUG_P(x) LogMessage(X_INFO, x"\n");
+#define DEBUG_P(x) DebugF(x"\n")
#else
#define DEBUG_P(x) /**/
#endif
@@ -267,13 +267,13 @@ ProcVidModeGetModeLine(ClientPtr client)
rep.vtotal = VidModeGetModeValue(mode, VIDMODE_V_TOTAL);
rep.flags = VidModeGetModeValue(mode, VIDMODE_FLAGS);
-LogMessage(X_INFO, "GetModeLine - scrn: %d clock: %ld\n",
- stuff->screen, (unsigned long) rep.dotclock);
-LogMessage(X_INFO, "GetModeLine - hdsp: %d hbeg: %d hend: %d httl: %d\n",
- rep.hdisplay, rep.hsyncstart, rep.hsyncend, rep.htotal);
-LogMessage(X_INFO, " vdsp: %d vbeg: %d vend: %d vttl: %d
flags: %ld\n",
- rep.vdisplay, rep.vsyncstart, rep.vsyncend,
- rep.vtotal, (unsigned long) rep.flags);
+DebugF("GetModeLine - scrn: %d clock: %ld\n",
+ stuff->screen, (unsigned long) rep.dotclock);
+DebugF("GetModeLine - hdsp: %d hbeg: %d hend: %d httl: %d\n",
+ rep.hdisplay, rep.hsyncstart, rep.hsyncend, rep.htotal);
+DebugF(" vdsp: %d vbeg: %d vend: %d vttl: %d flags: %ld\n",
+ rep.vdisplay, rep.vsyncstart, rep.vsyncend,
+ rep.vtotal, (unsigned long) rep.flags);
/*
* Older servers sometimes had server privates that the VidMode
@@ -483,23 +483,23 @@ ProcVidModeAddModeLine(ClientPtr client)
stuff->after_vtotal = oldstuff->after_vtotal;
stuff->after_flags = oldstuff->after_flags;
}
-LogMessage(X_INFO, "AddModeLine - scrn: %d clock: %ld\n",
- (int) stuff->screen, (unsigned long) stuff->dotclock);
-LogMessage(X_INFO, "AddModeLine - hdsp: %d hbeg: %d hend: %d httl: %d\n",
- stuff->hdisplay, stuff->hsyncstart,
- stuff->hsyncend, stuff->htotal);
-LogMessage(X_INFO, " vdsp: %d vbeg: %d vend: %d vttl: %d
flags: %ld\n",
- stuff->vdisplay, stuff->vsyncstart, stuff->vsyncend,
- stuff->vtotal, (unsigned long) stuff->flags);
-LogMessage(X_INFO, " after - scrn: %d clock: %ld\n",
- (int) stuff->screen, (unsigned long) stuff->after_dotclock);
-LogMessage(X_INFO, " hdsp: %d hbeg: %d hend: %d httl: %d\n",
- stuff->after_hdisplay, stuff->after_hsyncstart,
- stuff->after_hsyncend, stuff->after_htotal);
-LogMessage(X_INFO, " vdsp: %d vbeg: %d vend: %d vttl: %d
flags: %ld\n",
- stuff->after_vdisplay, stuff->after_vsyncstart,
- stuff->after_vsyncend, stuff->after_vtotal,
- (unsigned long) stuff->after_flags);
+DebugF("AddModeLine - scrn: %d clock: %ld\n",
+ (int) stuff->screen, (unsigned long) stuff->dotclock);
+DebugF("AddModeLine - hdsp: %d hbeg: %d hend: %d httl: %d\n",
+ stuff->hdisplay, stuff->hsyncstart,
+ stuff->hsyncend, stuff->htotal);
+DebugF(" vdsp: %d vbeg: %d vend: %d vttl: %d flags: %ld\n",
+ stuff->vdisplay, stuff->vsyncstart, stuff->vsyncend,
+ stuff->vtotal, (unsigned long) stuff->flags);
+DebugF(" after - scrn: %d clock: %ld\n",
+ (int) stuff->screen, (unsigned long) stuff->after_dotclock);
+DebugF(" hdsp: %d hbeg: %d hend: %d httl: %d\n",
+ stuff->after_hdisplay, stuff->after_hsyncstart,
+ stuff->after_hsyncend, stuff->after_htotal);
+DebugF(" vdsp: %d vbeg: %d vend: %d vttl: %d flags: %ld\n",
+ stuff->after_vdisplay, stuff->after_vsyncstart,
+ stuff->after_vsyncend, stuff->after_vtotal,
+ (unsigned long) stuff->after_flags);
if
Re: [PATCH xserver 1/3] present: Move msc_is_(equal_or_)after to the top of present.c
On Wed, Feb 24, 2016 at 04:52:57PM +0900, Michel Dänzer wrote: > From: Michel Dänzer <michel.daen...@amd.com> > > To make them usable from any other function in the file. No functional > change. > > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -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: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 2/3] present: Requeue if flip driver hook fails and target MSC not reached
On Wed, Feb 24, 2016 at 04:52:58PM +0900, Michel Dänzer wrote: > From: Michel Dänzer <michel.daen...@amd.com> > > For flipping, we wait for the MSC before the target MSC and then call > the driver flip hook. If the latter fails, we have to wait for the > target MSC before falling back to a copy, or else it's executed too > early. > > Fixes glxgears running at unbounded framerate (not synchronized to the > refresh rate) in fullscreen if the driver flip hook fails. > > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -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: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 3/3] present: Only requeue if target MSC is not reached after an unflip
On Wed, Feb 24, 2016 at 04:52:59PM +0900, Michel Dänzer wrote: > From: Michel Dänzer <michel.daen...@amd.com> > > While present_pixmap decrements target_msc by 1 for present_queue_vblank, > it leaves the original vblank->target_msc intact. So incrementing the > latter for requeueing resulted in the requeued presentation being > executed too late. My mistake. Yes, the local target_msc is decremented but after vblank->target_msc is assigned. > Also, no need to requeue if the target MSC is already reached. > > This further reduces stutter when a popup menu appears on top of a > flipping fullscreen window. > > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -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: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 3/3] present: Call present_restore_screen_pixmap from present_set_abort_flip
On Fri, Feb 19, 2016 at 11:39:12AM +0900, Michel Dänzer wrote: > From: Michel Dänzer <michel.daen...@amd.com> > > After present_set_abort_flip, the screen pixmap will be used for all > screen drawing, so we need to restore the current flip pixmap contents > to the screen pixmap here as well. > > Improves flashing / stutter e.g. when something like a popup menu appears > on top of a flipping fullscreen window or when switching out of > fullscreen. > > Note that this means present_set_abort_flip now relies on screen->root > being non-NULL, but that's already the case in other present code. It is true that we cannot schedule a flip without screen->root (though present_check_flip would crash rather than reject the call). > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -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: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 2/3] present: Factor code for restoring screen pixmap out of present_unflip
On Fri, Feb 19, 2016 at 11:39:11AM +0900, Michel Dänzer wrote: > From: Michel Dänzer <michel.daen...@amd.com> > > The following fix will use the refactored function. > > Signed-off-by: Michel Dänzer <michel.daen...@amd.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -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: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 1/3] present: Only update screen pixmap from flip pixmap once per unflip
On Fri, Feb 19, 2016 at 11:39:10AM +0900, Michel Dänzer wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> present_unflip may be called several times from present_check_flip_window
> during the same unflip. We can only copy to the screen pixmap the first
> time, otherwise we may scribble over other windows. The flip pixmap
> contents don't get updated after the first time anyway.
>
> Fixes at least the following problems, which were introduced by commit
> 806470b9 ("present: Copy unflip contents back to the Screen Pixmap"):
>
> On xfwm4 without compositing, run glxgears and put its window into
> fullscreen mode to start flipping. While in fullscreen, open the xfwm4
> window menu by pressing Alt-Space. The window menu was invisible most
> of the time because it was getting scribbled over by a repeated unflip
> copy.
>
> When switching a flipping window out of fullscreen, a repeated unflip
> copy could leave artifacts of the flip pixmap on the desktop.
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
And the ordering is better: we should do the restoration of the contents
before we restore the window->pixmap linkage.
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
-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: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] dri2: Use the work queue to manage client sleeps
On Thu, Feb 11, 2016 at 05:41:16PM +, Chris Wilson wrote:
> On Wed, Feb 10, 2016 at 11:51:18AM -0500, Adam Jackson wrote:
> > @@ -983,7 +990,7 @@ DRI2WakeClient(ClientPtr client, DrawablePtr pDraw, int
> > frame,
> > {
> > ScreenPtr pScreen = pDraw->pScreen;
> > DRI2DrawablePtr pPriv;
> > -
> > +t
>
> Without this,
> Tested-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
Drat, valgrind turned up something obnoxious:
==8695== Invalid write of size 8
==8695==at 0x5A74E9: dri2ClientWake (in /opt/xorg/bin/Xorg)
==8695==by 0x43F811: ProcessWorkQueue (in /opt/xorg/bin/Xorg)
==8695==by 0x5DA640: WaitForSomething (in /opt/xorg/bin/Xorg)
==8695==by 0x4397E0: Dispatch (in /opt/xorg/bin/Xorg)
==8695==by 0x43E8B9: dix_main (in /opt/xorg/bin/Xorg)
==8695==by 0x6CD5EC4: (below main) (libc-start.c:287)
==8695== Address 0xcf4c688 is 56 bytes inside a block of size 144 free'd
==8695==at 0x4C2BE10: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8695==by 0x5A7AB9: DRI2DrawableGone (in /opt/xorg/bin/Xorg)
==8695==by 0x467EE6: FreeResource (in /opt/xorg/bin/Xorg)
==8695==by 0x4336D6: ProcDestroyWindow (in /opt/xorg/bin/Xorg)
==8695==by 0x439A85: Dispatch (in /opt/xorg/bin/Xorg)
==8695==by 0x43E8B9: dix_main (in /opt/xorg/bin/Xorg)
==8695==by 0x6CD5EC4: (below main) (libc-start.c:287)
==8695==
Fix incoming; if we remove limitation to only allow one DRI2 client to
block (thus allowing multiple clients to wait on a MSC on the root for
instance) we can use the ClientSleep to keep track of all the pending
wake ups, with just an introduction of ClientSignalAll.
-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: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 2/2] dri2: Allow many blocked clients per-drawable
This patch was motivated by the need to fix the use-after-free in
dri2ClientWake, but in doing so removes an arbitrary restriction that
limits DRI2 to only blocking the first client on each drawable. In order
to fix the use-after-free, we need to avoid touching our privates in the
ClientSleep callback and so we want to only use that external list as
our means of controlling sleeps and wakeups. We thus have a list of
sleeping clients at our disposal and can manage multiple events and
sources.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
hw/xfree86/dri2/dri2.c | 130 +++--
1 file changed, 71 insertions(+), 59 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index f9d818c..d55be19 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -90,8 +90,6 @@ typedef struct _DRI2Drawable {
DRI2BufferPtr *buffers;
int bufferCount;
unsigned int swapsPending;
-ClientPtr blockedClient;
-Bool blockedOnMsc;
int swap_interval;
CARD64 swap_count;
int64_t target_sbc; /* -1 means no SBC wait outstanding */
@@ -99,6 +97,7 @@ typedef struct _DRI2Drawable {
CARD64 last_swap_msc; /* msc at completion of most recent swap */
CARD64 last_swap_ust; /* ust at completion of most recent swap */
int swap_limit; /* for N-buffering */
+unsigned blocked[3];
Bool needInvalidate;
int prime_id;
PixmapPtr prime_slave_pixmap;
@@ -139,6 +138,44 @@ typedef struct _DRI2Screen {
static void
destroy_buffer(DrawablePtr pDraw, DRI2BufferPtr buffer, int prime_id);
+enum DRI2WakeType {
+WAKE_SBC,
+WAKE_MSC,
+WAKE_SWAP,
+};
+
+#define Wake(c, t) (void *)((uintptr_t)(c) | (t))
+
+static Bool
+dri2WakeClient(ClientPtr client, void *closure)
+{
+ClientWakeup(client);
+return TRUE;
+}
+
+static Bool
+dri2WakeAll(ClientPtr client, DRI2DrawablePtr pPriv, enum DRI2WakeType t)
+{
+int count;
+
+if (!pPriv->blocked[t])
+return FALSE;
+
+count = ClientSignalAll(client, dri2WakeClient, Wake(pPriv, t));
+pPriv->blocked[t] -= count;
+return count;
+}
+
+static Bool
+dri2Sleep(ClientPtr client, DRI2DrawablePtr pPriv, enum DRI2WakeType t)
+{
+if (ClientSleep(client, dri2WakeClient, Wake(pPriv, t))) {
+pPriv->blocked[t]++;
+return TRUE;
+}
+return FALSE;
+}
+
static DRI2ScreenPtr
DRI2GetScreen(ScreenPtr pScreen)
{
@@ -210,8 +247,6 @@ DRI2AllocateDrawable(DrawablePtr pDraw)
pPriv->buffers = NULL;
pPriv->bufferCount = 0;
pPriv->swapsPending = 0;
-pPriv->blockedClient = NULL;
-pPriv->blockedOnMsc = FALSE;
pPriv->swap_count = 0;
pPriv->target_sbc = -1;
pPriv->swap_interval = 1;
@@ -219,6 +254,7 @@ DRI2AllocateDrawable(DrawablePtr pDraw)
if (!ds->GetMSC || !(*ds->GetMSC) (pDraw, , >last_swap_target))
pPriv->last_swap_target = 0;
+memset(pPriv->blocked, 0, sizeof(pPriv->blocked));
pPriv->swap_limit = 1; /* default to double buffering */
pPriv->last_swap_msc = 0;
pPriv->last_swap_ust = 0;
@@ -258,12 +294,7 @@ DRI2SwapLimit(DrawablePtr pDraw, int swap_limit)
if (pPriv->swapsPending >= pPriv->swap_limit)
return TRUE;
-if (pPriv->target_sbc == -1 && !pPriv->blockedOnMsc) {
-if (pPriv->blockedClient) {
-ClientSignal(pPriv->blockedClient);
-}
-}
-
+dri2WakeAll(CLIENT_SIGNAL_ANY, pPriv, WAKE_SWAP);
return TRUE;
}
@@ -412,8 +443,9 @@ DRI2DrawableGone(void *p, XID id)
(*pDraw->pScreen->DestroyPixmap)(pPriv->redirectpixmap);
}
-if (pPriv->blockedClient)
-ClientSignal(pPriv->blockedClient);
+dri2WakeAll(CLIENT_SIGNAL_ANY, pPriv, WAKE_SWAP);
+dri2WakeAll(CLIENT_SIGNAL_ANY, pPriv, WAKE_MSC);
+dri2WakeAll(CLIENT_SIGNAL_ANY, pPriv, WAKE_SBC);
free(pPriv);
@@ -689,15 +721,6 @@ 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
@@ -715,26 +738,17 @@ DRI2ThrottleClient(ClientPtr client, DrawablePtr pDraw)
return FALSE;
/* Throttle to swap limit */
-if ((pPriv->swapsPending >= pPriv->swap_limit) && !pPriv->blockedClient) {
-ResetCurrentRequest(client);
-client->sequence--;
-ClientSleep(client, dri2ClientWake, pPriv);
-pPriv->blockedClient = client;
-return TRUE;
+if (pPriv->swapsPending >= pPriv->swap_lim
[PATCH xserver 1/2] dix: Add ClientSignalAll()
This is a variant of ClientSignal() that signals all clients with an
optional matching sleeping client, function and closure.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
dix/dixutils.c | 22 ++
include/dix.h | 8
2 files changed, 30 insertions(+)
diff --git a/dix/dixutils.c b/dix/dixutils.c
index 205550e..b6b0023 100644
--- a/dix/dixutils.c
+++ b/dix/dixutils.c
@@ -620,6 +620,28 @@ ClientSignal(ClientPtr client)
return FALSE;
}
+int
+ClientSignalAll(ClientPtr client, ClientSleepProcPtr function, void *closure)
+{
+SleepQueuePtr q;
+int count = 0;
+
+for (q = sleepQueue; q; q = q->next) {
+if (!(client == CLIENT_SIGNAL_ANY || q->client == client))
+continue;
+
+if (!(function == CLIENT_SIGNAL_ANY || q->function == function))
+continue;
+
+if (!(closure == CLIENT_SIGNAL_ANY || q->closure == closure))
+continue;
+
+count += QueueWorkProc(q->function, q->client, q->closure);
+}
+
+return count;
+}
+
void
ClientWakeup(ClientPtr client)
{
diff --git a/include/dix.h b/include/dix.h
index 921156b..d49d055 100644
--- a/include/dix.h
+++ b/include/dix.h
@@ -255,6 +255,14 @@ extern _X_EXPORT Bool ClientSleep(ClientPtr client,
extern _X_EXPORT Bool ClientSignal(ClientPtr /*client */ );
#endif /* ___CLIENTSIGNAL_DEFINED___ */
+#ifndef ___CLIENTSIGNALALL_DEFINED___
+#define ___CLIENTSIGNALALL_DEFINED___
+#define CLIENT_SIGNAL_ANY ((void *)-1)
+extern _X_EXPORT int ClientSignalAll(ClientPtr /*client*/,
+ ClientSleepProcPtr /*function*/,
+ void * /*closure*/);
+#endif /* ___CLIENTSIGNALALL_DEFINED___ */
+
extern _X_EXPORT void ClientWakeup(ClientPtr /*client */ );
extern _X_EXPORT Bool ClientIsAsleep(ClientPtr /*client */ );
--
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: [PATCH xserver] dri2: Use the work queue to manage client sleeps
On Wed, Feb 10, 2016 at 11:51:18AM -0500, Adam Jackson wrote:
> @@ -983,7 +990,7 @@ DRI2WakeClient(ClientPtr client, DrawablePtr pDraw, int
> frame,
> {
> ScreenPtr pScreen = pDraw->pScreen;
> DRI2DrawablePtr pPriv;
> -
> +t
Without this,
Tested-by: Chris Wilson <ch...@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
-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: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 2/2] dix: Disable AttendClient() operation during client teardown
commit e43abdce964f5ed9689cf908af8c305b39a5dd36
Author: Chris Wilson <ch...@chris-wilson.co.uk>
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 <wol...@onsneteindhoven.nl>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94074
Testcase: dri2-race/client
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Cc: Adam Jackson <a...@nwnk.net>
---
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
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 <ch...@chris-wilson.co.uk>
Cc: Adam Jackson <a...@nwnk.net>
---
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
[PATCH xserver 3/4] dri2: Only create one unnamed reference per Drawable per Client
This workarounds issues in mesa and Mali that likes to create a new
DRI2Drawble per context and per frame, respectively. The idea is that we
only create one unnamed reference per Client on each Drawable that is
never destroyed - and we make the assumption that the only caller is
the DRI2 dispatcher and thus we don't need to check that the invalidate
handler is the same. Every DRI2Drawable reference sends an invalidate
event, and so not only do we have a slow memory leak, we also suffer a
performance loss as the Clients create more and more references to the
same Drawable - unless we limit them to a single reference each.
The issue was first reported 5^H 6 years ago by Pauli Nieminen and I have
incorporated his patches here. His improvement was to add a reference
count to the per-Client unnamed reference and by doing so could support
DRI2DestroyDrawable again. However, it remains the case that as the
lifecycles between the GLXDrawable (DRI2Drawable) and the parent
Drawable are decoupled, mesa cannot call DRI2DestroyDrawable on
Drawables it did not create (or else risk generating BadDrawable runtime
errors), see mesa commit 4ebf07a426771b62123e5fcb5a8be0de24037af1
Author: Kristian Høgsberg <k...@bitplanet.net>
Date: Mon Sep 13 08:39:42 2010 -0400
glx: Don't destroy DRI2 drawables for legacy glx drawables
For GLX 1.3 drawables, we can destroy the DRI2 drawable when the GLX
drawable is destroyed. However, for legacy drawables, there os no
good way of knowing when the application is done with it, so we just
let the DRI2 drawable linger on the server. The server will destroy
the DRI2 drawable when it destroys the X drawable or the client exits
anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=30109
and as such it rules out both using named references by the Clients and
the reference ever being reaped.
Note Present incorporates its own version of this type of reference leak.
v2: Incorporate refcounting of the unnamed reference by Pauli Nieminen.
Cc: Daniel Drake <dr...@endlessm.com>
Link: https://freedesktop.org/patch/19695/
Link: http://lists.x.org/archives/xorg-devel/2010-November/014783.html
Link: http://lists.x.org/archives/xorg-devel/2010-November/014782.html
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
hw/xfree86/dri2/dri2.c| 57 +++
hw/xfree86/dri2/dri2ext.c | 4 ++--
2 files changed, 55 insertions(+), 6 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 4dc40f8..2f05c64 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -275,11 +275,24 @@ DRI2SwapLimit(DrawablePtr pDraw, int swap_limit)
typedef struct DRI2DrawableRefRec {
XID pid;
+unsigned int refcnt;
DRI2InvalidateProcPtr invalidate;
void *priv;
struct xorg_list link;
} DRI2DrawableRefRec, *DRI2DrawableRefPtr;
+static DRI2DrawableRefPtr
+DRI2FindClientDrawableRef(ClientPtr client, DRI2DrawablePtr pPriv)
+{
+DRI2DrawableRefPtr ref;
+
+xorg_list_for_each_entry(ref, >reference_list, link)
+if (ref->refcnt && CLIENT_ID(ref->pid) == client->index)
+return ref;
+
+return NULL;
+}
+
int
DRI2CreateDrawable(ClientPtr client, DrawablePtr pDraw, XID pid,
DRI2InvalidateProcPtr invalidate, void *priv)
@@ -295,16 +308,34 @@ DRI2CreateDrawable(ClientPtr client, DrawablePtr pDraw,
XID pid,
pPriv->prime_id = dri2ClientPrivate(client)->prime_id;
+if (pid == 0) {
+ref = DRI2FindClientDrawableRef(client, pPriv);
+if (ref) {
+ref->refcnt++;
+assert(ref->invalidate == invalidate);
+assert(ref->priv == priv);
+return Success;
+}
+}
+
ref = malloc(sizeof *ref);
if (ref == NULL)
return BadAlloc;
-if (!AddResource(pid, dri2ReferenceRes, ref)) {
+if (pid == 0) {
+ref->refcnt = 1;
+ref->pid = FakeClientID(client->index);
+}
+else {
+ref->refcnt = 0;
+ref->pid = pid;
+}
+
+if (!AddResource(ref->pid, dri2ReferenceRes, ref)) {
free(ref);
return BadAlloc;
}
-ref->pid = pid;
ref->invalidate = invalidate;
ref->priv = priv;
xorg_list_add(>link, >reference_list);
@@ -313,9 +344,27 @@ DRI2CreateDrawable(ClientPtr client, DrawablePtr pDraw,
XID pid,
}
int
-DRI2DestroyDrawable(ClientPtr client, DrawablePtr pDraw, XID id)
+DRI2DestroyDrawable(ClientPtr client, DrawablePtr pDraw, XID pid)
{
-FreeResourceByType(id, dri2ReferenceRes, FALSE);
+if (pid == 0) {
+DRI2DrawablePtr pPriv;
+DRI2DrawableRefPtr ref;
+
+pPriv = DRI2GetDrawable(pDraw);
+if (pPriv == NULL)
+return BadDrawable;
+
+ref = DRI2FindClientDrawableRef(client, pPriv);
+if (re
[PATCH xserver 2/4] dri2: Split resource tracking for DRI2Drawable and references to them
In order to ease resource tracking, disentangle DRI2Drawable XIDs from
their references. This will be used in later patches to first limit the
object leak from unnamed references created on behalf of Clients and
then never destroy, and then to allow Clients to explicit manage their
references to DRI2Drawables.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
glx/glxdri2.c | 10 ++--
hw/xfree86/dri2/dri2.c| 136 ++
hw/xfree86/dri2/dri2.h| 11 ++--
hw/xfree86/dri2/dri2ext.c | 6 +-
4 files changed, 66 insertions(+), 97 deletions(-)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 89ad808..d7f1436 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -105,7 +105,7 @@ __glXDRIdrawableDestroy(__GLXdrawable * drawable)
__GLXDRIdrawable *private = (__GLXDRIdrawable *) drawable;
const __DRIcoreExtension *core = private->screen->core;
-FreeResource(private->dri2_id, FALSE);
+DRI2DestroyDrawable(NULL, private->base.pDraw, private->dri2_id);
(*core->destroyDrawable) (private->driDrawable);
@@ -602,7 +602,7 @@ __glXDRIscreenCreateContext(__GLXscreen * baseScreen,
}
static void
-__glXDRIinvalidateBuffers(DrawablePtr pDraw, void *priv, XID id)
+__glXDRIinvalidateBuffers(DrawablePtr pDraw, void *priv)
{
__GLXDRIdrawable *private = priv;
__GLXDRIscreen *screen = private->screen;
@@ -641,9 +641,9 @@ __glXDRIscreenCreateDrawable(ClientPtr client,
private->base.waitGL = __glXDRIdrawableWaitGL;
private->base.waitX = __glXDRIdrawableWaitX;
-ret = DRI2CreateDrawable2(client, pDraw, drawId,
- __glXDRIinvalidateBuffers, private,
- >dri2_id);
+private->dri2_id = FakeClientID(client->index);
+ret = DRI2CreateDrawable(client, pDraw, private->dri2_id,
+ __glXDRIinvalidateBuffers, private);
if (cx != lastGLContext) {
lastGLContext = cx;
cx->makeCurrent(cx);
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index bbff11c..4dc40f8 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -68,16 +68,16 @@ static DevPrivateKeyRec dri2PixmapPrivateKeyRec;
static DevPrivateKeyRec dri2ClientPrivateKeyRec;
-#define dri2ClientPrivateKey ()
-
-#define dri2ClientPrivate(_pClient)
(dixLookupPrivate(&(_pClient)->devPrivates, \
- dri2ClientPrivateKey))
-
typedef struct _DRI2Client {
int prime_id;
} DRI2ClientRec, *DRI2ClientPtr;
-static RESTYPE dri2DrawableRes;
+static DRI2ClientPtr dri2ClientPrivate(ClientPtr pClient)
+{
+return dixLookupPrivate(>devPrivates, );
+}
+
+static RESTYPE dri2DrawableRes, dri2ReferenceRes;
typedef struct _DRI2Screen *DRI2ScreenPtr;
@@ -203,6 +203,11 @@ DRI2AllocateDrawable(DrawablePtr pDraw)
if (pPriv == NULL)
return NULL;
+if (!AddResource(pDraw->id, dri2DrawableRes, pPriv)) {
+free(pPriv);
+return NULL;
+}
+
pPriv->dri2_screen = ds;
pPriv->drawable = pDraw;
pPriv->width = pDraw->width;
@@ -269,49 +274,37 @@ DRI2SwapLimit(DrawablePtr pDraw, int swap_limit)
}
typedef struct DRI2DrawableRefRec {
-XID id;
-XID dri2_id;
+XID pid;
DRI2InvalidateProcPtr invalidate;
void *priv;
struct xorg_list link;
} DRI2DrawableRefRec, *DRI2DrawableRefPtr;
-static DRI2DrawableRefPtr
-DRI2LookupDrawableRef(DRI2DrawablePtr pPriv, XID id)
+int
+DRI2CreateDrawable(ClientPtr client, DrawablePtr pDraw, XID pid,
+ DRI2InvalidateProcPtr invalidate, void *priv)
{
+DRI2DrawablePtr pPriv;
DRI2DrawableRefPtr ref;
-xorg_list_for_each_entry(ref, >reference_list, link) {
-if (ref->id == id)
-return ref;
-}
-
-return NULL;
-}
+pPriv = DRI2GetDrawable(pDraw);
+if (pPriv == NULL)
+pPriv = DRI2AllocateDrawable(pDraw);
+if (pPriv == NULL)
+return BadAlloc;
-static int
-DRI2AddDrawableRef(DRI2DrawablePtr pPriv, XID id, XID dri2_id,
- DRI2InvalidateProcPtr invalidate, void *priv)
-{
-DRI2DrawableRefPtr ref;
+pPriv->prime_id = dri2ClientPrivate(client)->prime_id;
ref = malloc(sizeof *ref);
if (ref == NULL)
return BadAlloc;
-if (!AddResource(dri2_id, dri2DrawableRes, pPriv)) {
+if (!AddResource(pid, dri2ReferenceRes, ref)) {
free(ref);
return BadAlloc;
}
-if (!DRI2LookupDrawableRef(pPriv, id))
-if (!AddResource(id, dri2DrawableRes, pPriv)) {
-FreeResourceByType(dri2_id, dri2DrawableRes, TRUE);
-free(ref);
-return BadAlloc;
-}
-ref->id = id;
-ref->dri2_id = dri2_id;
+ref->pid = pid;
ref->invalidate = invalidate;
ref->priv = pri
[PATCH xserver 4/4] dri2: Unblock Clients on Drawable release
If the Window is destroyed by another client, such as the window manager, the original client may be blocked by DRI2 awaiting a vblank event. When this happens, DRI2DrawableGone forgets to unblock that client and so the wait never completes. Note Present/xshmfence is also suspectible to this race. Testcase: dri2-race/manager Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com> --- hw/xfree86/dri2/dri2.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c index 2f05c64..80a601e 100644 --- a/hw/xfree86/dri2/dri2.c +++ b/hw/xfree86/dri2/dri2.c @@ -416,6 +416,9 @@ DRI2DrawableGone(void *p, XID id) (*pDraw->pScreen->DestroyPixmap)(pPriv->redirectpixmap); } +if (pPriv->blockedClient) +AttendClient(pPriv->blockedClient); + free(pPriv); return Success; -- 2.7.0 ___ 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
[PATCH xserver 1/4] dri2: Only invalidate the immediate Window upon SetWindowPixmap
All callers of SetWindowPixmap will themselves be traversing the Window
heirachy updating the backing Pixmap of each child and so we can forgo
doing the identical traversal inside the DRI2SetWindowPixmap handler.
Reported-by: Loïc Yhuel <loic.yh...@gmail.com>
Link: http://lists.x.org/archives/xorg-devel/2015-February/045638.html
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
hw/xfree86/dri2/dri2.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 60ea6dd..bbff11c 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -1385,8 +1385,7 @@ DRI2ConfigNotify(WindowPtr pWin, int x, int y, int w, int
h, int bw,
static void
DRI2SetWindowPixmap(WindowPtr pWin, PixmapPtr pPix)
{
-DrawablePtr pDraw = (DrawablePtr) pWin;
-ScreenPtr pScreen = pDraw->pScreen;
+ScreenPtr pScreen = pWin->drawable.pScreen;
DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
pScreen->SetWindowPixmap = ds->SetWindowPixmap;
@@ -1394,7 +1393,7 @@ DRI2SetWindowPixmap(WindowPtr pWin, PixmapPtr pPix)
ds->SetWindowPixmap = pScreen->SetWindowPixmap;
pScreen->SetWindowPixmap = DRI2SetWindowPixmap;
-DRI2InvalidateDrawableAll(pDraw);
+DRI2InvalidateDrawable(>drawable);
}
#define MAX_PRIME DRI2DriverPrimeMask
--
2.7.0
___
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 only lists mode after a while of waiting
On Mon, Dec 14, 2015 at 10:02:41AM +, Daniel Menet wrote: >New to the list, please bear with me and give me hints if I violate any >rules. >Its been a while now since I started facing an issue: xrandr only lists >mode after a while of waiting. I assume this happend after a upgrade of >some packages without an immediate reboot an occurred first after the >reboot. I accepted the situation for a while due to the lack of time. More >details are given at > > [1]http://unix.stackexchange.com/questions/240949/xrandr-only-lists-mode-after-a-while-of-waiting Should be resolved by now. It was just bug that mistakenly marked the first current-only probe as valid on the initial modesetting. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xrandr only lists mode after a while of waiting
On Mon, Dec 14, 2015 at 11:58:39AM +, Daniel Menet wrote: >Thanks Chris, that gives me some sense of optimism. Still I'm running Arch >Linux, all up to date - and still facing the issue. Since you mentioned >modesettigs I assume that this was a kernel related bug (I am not really >into the topic, correct me if I'm all wrong). This one is just the ddx. (Not that some people haven't stumbled into another issue with 4.4-rc...) > What release shipped the >fix? Would you mind providing a reference to a related bug report or >issue? I skimmed the release notes of 4.2.6 and 4.2.7 (Arch has 4.2.5) and >could not find a hint on a fix related to KMS. If you add an xf86-video-intel bug on https://bugs.archlinux.org/ and mention commit 627ef68a8cd7a51627d5b6a98cb0a5bdb1d9b534 Author: Chris Wilson <ch...@chris-wilson.co.uk> Date: Sat Oct 31 09:27:35 2015 + sna: Don't extend the display mode cache for an unknown output I am sure it will quickly get patched. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How to refresh the list of outputs detected by xrandr?
On Thu, Nov 19, 2015 at 02:19:25PM +0100, Łukasz Maśko wrote: > Hello. > I have a Dell E7250 laptop. I'm using it with docking stations with external > monitors connected. I have one dock at home and another one at work. The > monitors connected to them differ, both in models and connectors (and > therefore are recognized as different xrandr outputs). > > At home it looks like this: > $ xrandr > Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 > eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y > axis) 276mm x 156mm >1920x1080 60.02*+ 48.03 >1400x1050 59.98 >1280x1024 60.02 >1280x960 60.00 >1024x768 60.00 >800x600 60.3256.25 >640x480 59.94 > DP1 disconnected (normal left inverted right x axis y axis) > DP1-1 disconnected (normal left inverted right x axis y axis) > DP1-2 disconnected (normal left inverted right x axis y axis) > DP1-3 connected (normal left inverted right x axis y axis) >1440x900 59.89 + >1280x1024 75.0260.02 >1280x960 60.00 >1152x864 75.00 >1152x720 59.97 >1024x768 75.0860.00 >832x624 74.55 >800x600 75.0060.3256.25 >848x480 60.00 >640x480 75.0060.0059.94 >720x400 70.08 > DP2 disconnected (normal left inverted right x axis y axis) > HDMI1 disconnected (normal left inverted right x axis y axis) > HDMI2 disconnected (normal left inverted right x axis y axis) > VIRTUAL1 disconnected (normal left inverted right x axis y axis) > > while at work like this: > $ xrandr > Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 > eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y > axis) 276mm x 156mm >1920x1080 60.02*+ 48.03 >1400x1050 59.98 >1280x1024 60.02 >1280x960 60.00 >1024x768 60.00 >800x600 60.3256.25 >640x480 59.94 > DP1 disconnected (normal left inverted right x axis y axis) > DP1-1 connected (normal left inverted right x axis y axis) >1920x1080 60.00 + 50.0059.94 >1600x1200 60.00 >1680x1050 59.88 >1280x1024 60.02 >1440x900 59.90 >1280x960 60.00 >1280x800 59.91 >1280x720 60.0050.0059.94 >1024x768 60.00 >800x600 60.3256.25 >720x576 50.00 >720x480 60.0059.94 >640x480 60.0059.94 > DP1-2 disconnected (normal left inverted right x axis y axis) > DP1-3 disconnected (normal left inverted right x axis y axis) > DP2 disconnected (normal left inverted right x axis y axis) > HDMI1 disconnected (normal left inverted right x axis y axis) > HDMI2 disconnected (normal left inverted right x axis y axis) > VIRTUAL1 disconnected (normal left inverted right x axis y axis) > > > The problem is, that if I suspend my laptop while it is connected to one of > the docking stations, it remembers the layout of available monitors and when > I > dock it onto the other station and resume, it still shows me the old list of > outputs and modes. I need to undock it while running and dock it again to > make > it notify the change in outputs. > > Is there a software way to force xrandr to refresh its state and notify the > change in connected devices? The kernel is supposed to send a hotplug notification on resume that should result in the list being updated. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How to refresh the list of outputs detected by xrandr?
On Thu, Nov 19, 2015 at 02:39:21PM +0100, Łukasz Maśko wrote: > Dnia czwartek, 19 listopada 2015 13:27:37 Chris Wilson pisze: > [...] > > The kernel is supposed to send a hotplug notification on resume that > > should result in the list being updated. > > If I get you right, the kernel does not notify the change of a dock and > therefore does not notify X about the change? The usual report is "suspend, dock/undock, resume". Changing the dock should generate the usual hardware hotplug notifications. If the machine was suspended at the time, we have to fake the hotplug event on resume. > Is there a way to generate such notification using currently available > software tools, or am I limited to fix in the kernel to make it notify dock > change? Hmm, can't see a way to synthesize uevents. But still calling xrandr should be enough to do a forced reprobe of outputs. Without a hotplug event, there is a small 15s cache of the most recent probe. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: [PATCH] present: Fix Async swap logic
On Tue, Nov 03, 2015 at 09:14:51AM +0100, Axel Davy wrote:
> According to the spec, PresentOptionAsync should only
> trigger a different behaviour when the target msc has been reached.
>
> In this case if the driver is able to do async swaps, we use
> them to avoid a screen copy.
>
> When the target msc hasn't been reached yet, we want to use sync swaps.
>
> Signed-off-by: Axel Davy <axel.d...@ens.fr>
> ---
> I'm not sure for indentation, I tried to do the same than previous check
> present/present.c | 29 -
> 1 file changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/present/present.c b/present/present.c
> index beb4ff0..3b8679c 100644
> --- a/present/present.c
> +++ b/present/present.c
> @@ -836,19 +836,22 @@ present_pixmap(WindowPtr window,
> vblank->notifies = notifies;
> vblank->num_notifies = num_notifies;
>
> -if (!(options & PresentOptionAsync))
> -vblank->sync_flip = TRUE;
> -
> -if (!(options & PresentOptionCopy) &&
> -!((options & PresentOptionAsync) &&
> - (!screen_priv->info ||
> - !(screen_priv->info->capabilities & PresentCapabilityAsync))) &&
> -pixmap != NULL &&
> -present_check_flip (target_crtc, window, pixmap, vblank->sync_flip,
> valid, x_off, y_off))
> -{
> -vblank->flip = TRUE;
> -if (vblank->sync_flip)
> -target_msc--;
> +if (pixmap != NULL &&
> +!(options & PresentOptionCopy) &&
> +screen_priv->info) {
> +if (target_msc > crtc_msc &&
> +present_check_flip (target_crtc, window, pixmap, TRUE, valid,
> x_off, y_off))
> +{
> + vblank->flip = TRUE;
> + vblank->sync_flip = TRUE;
> + target_msc--;
> +} else if (target_msc == crtc_msc &&
> +(options & PresentOptionAsync) &&
> +(screen_priv->info->capabilities & PresentCapabilityAsync) &&
> +present_check_flip (target_crtc, window, pixmap, FALSE, valid,
> x_off, y_off))
> +{
> + vblank->flip = TRUE;
> +}
> }
For reference, this is how I fixed the async flip + swap elision:
t a/present/present.c b/present/present.c
index e9ccfb8..32522af 100644
--- a/present/present.c
+++ b/present/present.c
@@ -861,19 +861,19 @@ present_pixmap(WindowPtr window,
vblank->notifies = notifies;
vblank->num_notifies = num_notifies;
-if (!(options & PresentOptionAsync))
-vblank->sync_flip = TRUE;
-
-if (!(options & PresentOptionCopy) &&
-!((options & PresentOptionAsync) &&
- (!screen_priv->info ||
- !(screen_priv->info->capabilities & PresentCapabilityAsync))) &&
-pixmap != NULL &&
-present_check_flip (target_crtc, window, pixmap, vblank->sync_flip,
valid, x_off, y_off))
-{
-vblank->flip = TRUE;
-if (vblank->sync_flip)
+if (!(options & PresentOptionCopy) && pixmap != NULL) {
+if (options & PresentOptionAsync &&
+(screen_priv->info &&
+ screen_priv->info->capabilities & PresentCapabilityAsync) &&
+ present_check_flip (target_crtc, window, pixmap, FALSE, valid,
x_off, y_off)) {
+vblank->flip = TRUE;
+}
+else if (present_check_flip (target_crtc, window, pixmap, TRUE, valid,
x_off, y_off)) {
+vblank->flip = TRUE;
+vblank->sync_flip = TRUE;
target_msc--;
+} else if (options & PresentOptionAsync)
+target_msc++;
}
if (wait_fence) {
--
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] present: Fix Async swap logic
On Wed, Nov 04, 2015 at 10:48:40AM +0100, Axel Davy wrote:
> On 04/11/2015 10:40, Chris Wilson wrote:
> >On Tue, Nov 03, 2015 at 09:14:51AM +0100, Axel Davy wrote:
> >>+if (pixmap != NULL &&
> >>+!(options & PresentOptionCopy) &&
> >>+screen_priv->info) {
> >>+if (target_msc > crtc_msc &&
> >>+present_check_flip (target_crtc, window, pixmap, TRUE, valid,
> >>x_off, y_off))
> >>+{
> >>+ vblank->flip = TRUE;
> >>+ vblank->sync_flip = TRUE;
> >>+ target_msc--;
> >>+} else if (target_msc == crtc_msc &&
> >>+(options & PresentOptionAsync) &&
> >>+(screen_priv->info->capabilities & PresentCapabilityAsync) &&
> >>+present_check_flip (target_crtc, window, pixmap, FALSE, valid,
> >>x_off, y_off))
> >>+{
> >>+ vblank->flip = TRUE;
> >>+}
> >> }
> >For reference, this is how I fixed the async flip + swap elision:
> >
> >t a/present/present.c b/present/present.c
> >index e9ccfb8..32522af 100644
> >--- a/present/present.c
> >+++ b/present/present.c
> >@@ -861,19 +861,19 @@ present_pixmap(WindowPtr window,
> > vblank->notifies = notifies;
> > vblank->num_notifies = num_notifies;
> >-if (!(options & PresentOptionAsync))
> >-vblank->sync_flip = TRUE;
> >-
> >-if (!(options & PresentOptionCopy) &&
> >-!((options & PresentOptionAsync) &&
> >- (!screen_priv->info ||
> >- !(screen_priv->info->capabilities & PresentCapabilityAsync))) &&
> >-pixmap != NULL &&
> >-present_check_flip (target_crtc, window, pixmap, vblank->sync_flip,
> >valid, x_off, y_off))
> >-{
> >-vblank->flip = TRUE;
> >-if (vblank->sync_flip)
> >+if (!(options & PresentOptionCopy) && pixmap != NULL) {
> >+if (options & PresentOptionAsync &&
> >+(screen_priv->info &&
> >+ screen_priv->info->capabilities & PresentCapabilityAsync) &&
> >+present_check_flip (target_crtc, window, pixmap, FALSE, valid,
> >x_off, y_off)) {
> >+vblank->flip = TRUE;
> >+}
> >+else if (present_check_flip (target_crtc, window, pixmap, TRUE,
> >valid, x_off, y_off)) {
> >+vblank->flip = TRUE;
> >+vblank->sync_flip = TRUE;
> > target_msc--;
> >+} else if (options & PresentOptionAsync)
> >+target_msc++;
> > }
> > if (wait_fence) {
> >
> >
> Hi,
>
> Could you explain:
> . Why you increase target_msc when the Async option is requested ?
It's the fallthrough path where the client requested an async swap but
we cannot perform one and so must use a synchronous wait for the vblank
(in which case we actually wait for the vblank before target_msc, hence
the increment here to compenstae).
> . Why you check for Async flips first (isn't sync flips better when
> possible) ?
The choice is between using native async flips or emulating them through
sync flips. Native wins.
> To me the Async option isn't related particularly to Async flips.
> Async flips is just an optimization to handle it without a copy in
> the case you would need one.
It is described as being "perform the flip as soon as possible (if
target < current msc) without regard to synchronisation to vrefresh".
That says use tearing native async flips to me.
> http://cgit.freedesktop.org/xorg/proto/presentproto/tree/presentproto.txt#n212
> Given the spec, I believe when target_msc > crtc_msc, the behaviour
> should be the same with or without the flag, and thus you shouldn't
> increase target_msc.
Exactly, hence why we need to fudge it in the code to maintain the
requested msc (as the code fudges it again later on).
-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: How to setup independent screens with the Intel driver?
On Fri, Oct 30, 2015 at 04:58:49PM +0100, Boszormenyi Zoltan wrote: > Hi, > > I am using kernel 4.2.3, Xorg 1.16.4, Mesa 11.0.4 and the current > xf86-video-intel GIT tip > (commit be3748802398a741208715233d36935378ceff58) on an > OpenEmbedded / Yocto derived distro. > > This machine I have to configure and develop for is a POS machine with this > Intel chip: > > # lspci -s 00:02.0 > 00:02.0 VGA compatible controller: Intel Corporation Atom Processor > D4xx/D5xx/N4xx/N5xx > Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) > > Without a configuration file, I get clone mode with the two screens. > But I would like to setup two separate screens with :0.0 and :0.1 > without Xinerama or unified framebuffer, in order to make fullscreen > X apps cover only one of the screens. > > Below is the xorg.conf I am trying to use with the touchscreen configuration > omitted. > > - > Section "Monitor" > Identifier "Monitor-LVDS1" > EndSection > > Section "Monitor" > Identifier "Monitor-VGA1" > #Option "RightOf" "Monitor-LVDS1" > EndSection > > Section "Device" > Identifier "Intel0" > Driver "intel" > BusID "PCI:0:2:0" > Screen 0 > Option "AccelMethod" "sna" > Option "Monitor-LVDS1" "LVDS1" Option "ZaphodHeads" "LVDS1" > Option "TearFree" "on" > EndSection > > Section "Device" > Identifier "Intel1" > Driver "intel" > BusID "PCI:0:2:0" > Screen 1 > Option "AccelMethod" "sna" > Option "Monitor-VGA1" "VGA1" Option "ZaphodHeads" "VGA1" > Option "TearFree" "on" > EndSection -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How to setup independent screens with the Intel driver?
On Fri, Oct 30, 2015 at 08:00:46PM +0100, Boszormenyi Zoltan wrote: > 2015-10-30 19:15 keltezéssel, Chris Wilson írta: > > On Fri, Oct 30, 2015 at 06:17:50PM +0100, Boszormenyi Zoltan wrote: > >> In my case with this particular POS machine, the intended primary display, > >> the built-in LVDS with a touchscreen attached is apparently wired to pipe > >> 1. > >> > >> With this driver behaviour, I can't configure it to be kept as the default > >> :0.0 screen > >> if an external display is plugged in. Can this behaviour be changed? > > It would need another user parameter. There are several technical > > limitations that make automatic assignment difficult. So try > > > > commit 94d271b239d358f71ae0bcfcc31422a569d73d41 > > Author: Chris Wilson <ch...@chris-wilson.co.uk> > > Date: Fri Oct 30 18:07:37 2015 + > > > > sna: Allow pipes to be manually assigned to ZaphodHead > > -Chris > > Thanks for your work, I just tested it. At startup, it seems to work: > 1. it doesn't complain about invalid pipe > 2. cursor appears on :0 > 3. application appears on :0 > > Then as soon as I touch the touchscreen, the cursor jumps to :1 and > further cursor movements are on :1 from that point. I'm baffled. xinput fun? cursors in the driver are allocated per-CRTC and handled at a screen level. As far as I am aware, the driver only has to position a cursor at a certain coordinate on the framebuffer (and so has to translate that into a CRTC location). > Attached is my current configuration, hopefully I got it right. Looks fine to me. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How to setup independent screens with the Intel driver?
On Fri, Oct 30, 2015 at 05:56:35PM +0100, Boszormenyi Zoltan wrote: > 2015-10-30 17:46 keltezéssel, Boszormenyi Zoltan írta: > > 2015-10-30 17:36 keltezéssel, Chris Wilson írta: > >> On Fri, Oct 30, 2015 at 04:58:49PM +0100, Boszormenyi Zoltan wrote: > >>> Section "Device" > >>> Identifier "Intel0" > >>> Driver "intel" > >>> BusID "PCI:0:2:0" > >>> Screen 0 > >>> Option "AccelMethod" "sna" > >>> Option "Monitor-LVDS1" "LVDS1" > >> Option "ZaphodHeads" "LVDS1" > >> > >>> Option "TearFree" "on" > >>> EndSection > >>> > >>> Section "Device" > >>> Identifier "Intel1" > >>> Driver "intel" > >>> BusID "PCI:0:2:0" > >>> Screen 1 > >>> Option "AccelMethod" "sna" > >>> Option "Monitor-VGA1" "VGA1" > >> Option "ZaphodHeads" "VGA1" > >> > >>> Option "TearFree" "on" > >>> EndSection > >> -Chris > > I tried adding the ZaphodHeads option to the device sections before. > > It didn't work. The driver throws an error: > > > > [3114226.306] (II) intel(0): Using Kernel Mode Setting driver: i915, > > version 1.6.0 20150522 > > [3114226.307] (II) intel(1): Using Kernel Mode Setting driver: i915, > > version 1.6.0 20150522 > > [3114226.307] (--) intel(0): Integrated Graphics Chipset: Intel(R) Pineview > > G > > [3114226.308] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3; using a > > maximum of 2 threads > > [3114226.308] (==) intel(0): Depth 24, (--) framebuffer bpp 32 > > [3114226.308] (==) intel(0): RGB weight 888 > > [3114226.308] (==) intel(0): Default visual is TrueColor > > [3114226.308] (**) intel(0): Option "AccelMethod" "sna" > > [3114226.308] (**) intel(0): Option "ZaphodHeads" "LVDS1" > > [3114226.308] (**) intel(0): Option "TearFree" "on" > > [3114226.309] (EE) intel(0): LVDS1 is an invalid output for screen (pipe) 0 > > It seems the device pipe and screen matching doesn't work properly. > The driver seems to be assuming that its pipe numbers always match > the same X screen numbers. Assuming? That's how I documented it. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How to setup independent screens with the Intel driver?
On Fri, Oct 30, 2015 at 05:46:51PM +0100, Boszormenyi Zoltan wrote: > 2015-10-30 17:36 keltezéssel, Chris Wilson írta: > > On Fri, Oct 30, 2015 at 04:58:49PM +0100, Boszormenyi Zoltan wrote: > >> Section "Device" > >> Identifier "Intel0" > >> Driver "intel" > >> BusID "PCI:0:2:0" > >> Screen 0 > >> Option "AccelMethod" "sna" > >> Option "Monitor-LVDS1" "LVDS1" > > Option "ZaphodHeads" "LVDS1" > > > >> Option "TearFree" "on" > >> EndSection > >> > >> Section "Device" > >> Identifier "Intel1" > >> Driver "intel" > >> BusID "PCI:0:2:0" > >> Screen 1 > >> Option "AccelMethod" "sna" > >> Option "Monitor-VGA1" "VGA1" > > Option "ZaphodHeads" "VGA1" > > > >> Option "TearFree" "on" > >> EndSection > > -Chris > > I tried adding the ZaphodHeads option to the device sections before. > It didn't work. The driver throws an error: Swap around Screen 0 and Screen 1, i.e. use VGA in Screen 0 and LVDS1 in Screen 0. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How to setup independent screens with the Intel driver?
On Fri, Oct 30, 2015 at 06:17:50PM +0100, Boszormenyi Zoltan wrote: > 2015-10-30 18:03 keltezéssel, Chris Wilson írta: > > On Fri, Oct 30, 2015 at 05:56:35PM +0100, Boszormenyi Zoltan wrote: > >> 2015-10-30 17:46 keltezéssel, Boszormenyi Zoltan írta: > >>> 2015-10-30 17:36 keltezéssel, Chris Wilson írta: > >>>> On Fri, Oct 30, 2015 at 04:58:49PM +0100, Boszormenyi Zoltan wrote: > >>>>> Section "Device" > >>>>> Identifier "Intel0" > >>>>> Driver "intel" > >>>>> BusID "PCI:0:2:0" > >>>>> Screen 0 > >>>>> Option "AccelMethod" "sna" > >>>>> Option "Monitor-LVDS1" "LVDS1" > >>>> Option "ZaphodHeads" "LVDS1" > >>>> > >>>>> Option "TearFree" "on" > >>>>> EndSection > >>>>> > >>>>> Section "Device" > >>>>> Identifier "Intel1" > >>>>> Driver "intel" > >>>>> BusID "PCI:0:2:0" > >>>>> Screen 1 > >>>>> Option "AccelMethod" "sna" > >>>>> Option "Monitor-VGA1" "VGA1" > >>>> Option "ZaphodHeads" "VGA1" > >>>> > >>>>> Option "TearFree" "on" > >>>>> EndSection > >>>> -Chris > >>> I tried adding the ZaphodHeads option to the device sections before. > >>> It didn't work. The driver throws an error: > >>> > >>> [3114226.306] (II) intel(0): Using Kernel Mode Setting driver: i915, > >>> version 1.6.0 20150522 > >>> [3114226.307] (II) intel(1): Using Kernel Mode Setting driver: i915, > >>> version 1.6.0 20150522 > >>> [3114226.307] (--) intel(0): Integrated Graphics Chipset: Intel(R) > >>> Pineview G > >>> [3114226.308] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3; using a > >>> maximum of 2 threads > >>> [3114226.308] (==) intel(0): Depth 24, (--) framebuffer bpp 32 > >>> [3114226.308] (==) intel(0): RGB weight 888 > >>> [3114226.308] (==) intel(0): Default visual is TrueColor > >>> [3114226.308] (**) intel(0): Option "AccelMethod" "sna" > >>> [3114226.308] (**) intel(0): Option "ZaphodHeads" "LVDS1" > >>> [3114226.308] (**) intel(0): Option "TearFree" "on" > >>> [3114226.309] (EE) intel(0): LVDS1 is an invalid output for screen (pipe) > >>> 0 > >> It seems the device pipe and screen matching doesn't work properly. > >> The driver seems to be assuming that its pipe numbers always match > >> the same X screen numbers. > > Assuming? That's how I documented it. > > -Chris > > "man intel" on Fedora 22 doesn't says anything like that. Where is it > documented? Apparently in my imagination. I could have sworn that I wrote about the relationship between the Screen number and the CRTC it was assigned and how you needed to look at the xrandr output to work out possible arrangements. Probably lost in some bugzilla. > In my case with this particular POS machine, the intended primary display, > the built-in LVDS with a touchscreen attached is apparently wired to pipe 1. > > With this driver behaviour, I can't configure it to be kept as the default > :0.0 screen > if an external display is plugged in. Can this behaviour be changed? It would need another user parameter. There are several technical limitations that make automatic assignment difficult. So try commit 94d271b239d358f71ae0bcfcc31422a569d73d41 Author: Chris Wilson <ch...@chris-wilson.co.uk> Date: Fri Oct 30 18:07:37 2015 + sna: Allow pipes to be manually assigned to ZaphodHead -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[PATCH] os: Fix iteration over busfaults
Fixes a regression from
commit 41da295eb50fa08eaacd0ecde99f43a716fcb41a
Author: Keith Packard <kei...@keithp.com>
Date: Sun Nov 3 13:12:40 2013 -0800
Trap SIGBUS to handle truncated shared memory segments
that causes the SIGBUS handler to fail to chain up correctly and
corrupts nearby memory instead.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
os/busfault.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/os/busfault.c b/os/busfault.c
index d4afa6d..a2d433a 100644
--- a/os/busfault.c
+++ b/os/busfault.c
@@ -98,15 +98,16 @@ static void
busfault_sigaction(int sig, siginfo_t *info, void *param)
{
void*fault = info->si_addr;
-struct busfault *busfault = NULL;
+struct busfault *iter, *busfault = NULL;
void*new_addr;
/* Locate the faulting address in our list of shared segments
*/
-xorg_list_for_each_entry(busfault, , list) {
-if ((char *) busfault->addr <= (char *) fault && (char *) fault <
(char *) busfault->addr + busfault->size) {
-break;
-}
+xorg_list_for_each_entry(iter, , list) {
+ if ((char *) iter->addr <= (char *) fault && (char *) fault < (char *)
iter->addr + iter->size) {
+ busfault = iter;
+ break;
+ }
}
if (!busfault)
goto panic;
@@ -132,7 +133,7 @@ panic:
if (previous_busfault_sigaction)
(*previous_busfault_sigaction)(sig, info, param);
else
-FatalError("bus error");
+FatalError("bus error\n");
}
Bool
--
2.1.4
___
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
[xrandr] Pretty print modeFlags on unattached modes
For modes attached to an output we decode the modeFlags into their human
readable strings. For unattached modes, we currently do not print the
modeFlags at all - so continue the copy'n'paste for mode printing.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92025
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
xrandr.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xrandr.c b/xrandr.c
index bcaf247..a38417d 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -3372,9 +3372,15 @@ main (int argc, char **argv)
if (!(mode->modeFlags & ModeShown))
{
- printf (" %s (0x%x) %6.1fMHz\n",
+ int f;
+
+ printf (" %s (0x%x) %6.1fMHz",
mode->name, (int)mode->id,
(double)mode->dotClock / 100.0);
+ for (f = 0; mode_flags[f].flag; f++)
+ if (mode->modeFlags & mode_flags[f].flag)
+ printf (" %s", mode_flags[f].string);
+ printf("\n");
printf ("h: width %4d start %4d end %4d total %4d skew
%4d clock %6.1fKHz\n",
mode->width, mode->hSyncStart, mode->hSyncEnd,
mode->hTotal, mode->hSkew, mode_hsync (mode) / 1000);
--
2.5.1
___
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
[xrandr] Only use the current information when setting modes
Before we change the state (e.g. adding a mode or applying one to an
output), we query the screen resources for the right identifiers. This
should only use the current information rather than force a reprobe on
all hardware - not only can that reprobe be very slow (e.g. EDID
timeouts on the order of seconds), but it may perturb the setup that the
user is trying to configure.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
xrandr.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index 181c76e..dcfdde0 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -3325,7 +3325,7 @@ main (int argc, char **argv)
{
umode_t *m;
-get_screen (current);
+get_screen (True);
get_crtcs();
get_outputs();
@@ -3374,7 +3374,7 @@ main (int argc, char **argv)
{
output_t *output;
-get_screen (current);
+get_screen (True);
get_crtcs();
get_outputs();
@@ -3465,7 +3465,7 @@ main (int argc, char **argv)
if (!has_1_4)
fatal ("--setprovideroutputsource requires RandR 1.4\n");
- get_screen (current);
+ get_screen (True);
get_providers ();
provider = find_provider (_name);
@@ -3480,7 +3480,7 @@ main (int argc, char **argv)
if (!has_1_4)
fatal ("--setprovideroffloadsink requires RandR 1.4\n");
- get_screen (current);
+ get_screen (True);
get_providers ();
provider = find_provider (_name);
@@ -3490,7 +3490,7 @@ main (int argc, char **argv)
}
if (setit_1_2)
{
- get_screen (current);
+ get_screen (True);
get_crtcs ();
get_outputs ();
set_positions ();
@@ -3589,7 +3589,7 @@ main (int argc, char **argv)
exit(0);
}
- get_screen(current);
+ get_screen(True);
get_monitors(True);
get_crtcs();
get_outputs();
--
2.5.1
___
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] Only use the current information when setting modes
On Sun, Sep 13, 2015 at 12:14:57PM +0100, Chris Wilson wrote: > On Sun, Sep 13, 2015 at 01:08:11PM +0200, Mark Kettenis wrote: > > Seems you already can get the behaviour you want by specifying > > --current. Whereas there is no convenient way to force a probe, other > > than an explicit query? > > And there should not be. On KMS platforms regeneration of the RR > information is driven by hotplug events (either generated by the hw > itself or by a kernel worker emulating the notifications otherwise). An > explicit probe by the user should be the means of last resort not the > default. Also "xrandr" still does the explicit probe as the query is the default operation, and only using the current on queries requires a user option. -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] Only use the current information when setting modes
On Sun, Sep 13, 2015 at 01:08:11PM +0200, Mark Kettenis wrote: > > From: Chris Wilson <ch...@chris-wilson.co.uk> > > Date: Sun, 13 Sep 2015 11:40:37 +0100 > > > > Before we change the state (e.g. adding a mode or applying one to an > > output), we query the screen resources for the right identifiers. This > > should only use the current information rather than force a reprobe on > > all hardware - not only can that reprobe be very slow (e.g. EDID > > timeouts on the order of seconds), but it may perturb the setup that the > > user is trying to configure. > > How do you guarantee that that cached information isn't stale? There is no issue in that, since the user parameters are against the output from a previous run. If the configuration is stale then so are the xrandr parameters. > Seems you already can get the behaviour you want by specifying > --current. Whereas there is no convenient way to force a probe, other > than an explicit query? And there should not be. On KMS platforms regeneration of the RR information is driven by hotplug events (either generated by the hw itself or by a kernel worker emulating the notifications otherwise). An explicit probe by the user should be the means of last resort not the default. -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] Only use the current information when setting modes
On Sun, Sep 13, 2015 at 08:01:46PM +0200, Mark Kettenis wrote:
> > Date: Sun, 13 Sep 2015 12:14:57 +0100
> > From: Chris Wilson <ch...@chris-wilson.co.uk>
> >
> > On Sun, Sep 13, 2015 at 01:08:11PM +0200, Mark Kettenis wrote:
> > > > From: Chris Wilson <ch...@chris-wilson.co.uk>
> > > > Date: Sun, 13 Sep 2015 11:40:37 +0100
> > > >
> > > > Before we change the state (e.g. adding a mode or applying one to an
> > > > output), we query the screen resources for the right identifiers. This
> > > > should only use the current information rather than force a reprobe on
> > > > all hardware - not only can that reprobe be very slow (e.g. EDID
> > > > timeouts on the order of seconds), but it may perturb the setup that the
> > > > user is trying to configure.
> > >
> > > How do you guarantee that that cached information isn't stale?
> >
> > There is no issue in that, since the user parameters are against the
> > output from a previous run. If the configuration is stale then so are
> > the xrandr parameters.
>
> I bet tons of people have a script that runs xrandr to configure a
> projector connected to the VGA port on their laptop. Yes there is no
> guarantee that the parameters I give to xrandr match the current
> configuration. But if I connect the same projector (or even a
> different one) to the same VGA port I expect this script to work and
> make the display of my laptop appear on the projector. I expect this
> to work even when I connected the VGA cable after I started X.
If you relied on xrandr without checking for the existence of the output
first, you are describing a race condition. (Any use of xrandr is a race
condition!) To maintain the behaviour of providing that automagic probe,
you can extend get_outputs() to reprobe if the user requests a conflicting
operation, like
@@ -1800,10 +1800,26 @@ apply (void)
* Use current output state to complete the output list
*/
static void
-get_outputs (void)
+get_outputs (int use_current)
{
into;
output_t*q;
+int disconnected;
+
+do
+{
+if (res)
+{
+XRRFreeScreenResources(res);
+res = NULL;
+}
+
+get_screen (use_current);
+
+disconnected = 0;
+
+for (q = all_outputs; q; q = q->next)
+q->found = False;
for (o = 0; o < res->noutput; o++)
{
@@ -1872,7 +1888,16 @@ get_outputs (void)
}
set_output_info (output, res->outputs[o], output_info);
+disconnected +=
+output_info->connection == RR_Disconnected &&
+output_info->crtc;
}
+
+for (q = all_outputs; q; q = q->next)
+disconnected += !q->found;
+
+} while (disconnected && ++use_current == 0);
+
for (q = all_outputs; q; q = q->next)
{
if (!q->found)
> > > Seems you already can get the behaviour you want by specifying
> > > --current. Whereas there is no convenient way to force a probe, other
> > > than an explicit query?
> >
> > And there should not be. On KMS platforms regeneration of the RR
> > information is driven by hotplug events (either generated by the hw
> > itself or by a kernel worker emulating the notifications otherwise). An
> > explicit probe by the user should be the means of last resort not the
> > default.
>
> Well, that only works on KMS with udev. And only if the specific
> driver you're using has udev support.
>
> To me it seems that you're trying to solve this at the wrong level.
> If a driver (kernel or Xorg) has reliable hotplug support, shouldn't
> it be able to decide whether it needs to reread the EDID information
> of some monitor or not?
Eh? We already have multiple layers of caching. Howver users making
explicit reprobe requests have to override the caching just in case
the cache/hardware is broken. The issue is that xrandr does the
explicit by default (and similarly that very few pieces of software use
XRRGetScreenResourcesCurrent but there are a lot of silly (i.e. where
applications are only querying monitor layout with no desire to set
configurations) uses of XRRGetScreenResources).
-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] Xephyr: Paint with subimage for non-Glamor non-XSHM case
On Thu, May 21, 2015 at 04:13:12PM -0700, Ian Scott wrote:
This improves the case for when we paint an area without SHM.
Improves? Xephyr is very much broken since
commit a2b73da78de4e627965213d24a6c33f243a60eb6
Author: Julien Cristau jcris...@debian.org
Date: Sun Jun 20 00:05:40 2010 +0100
xcb_image_subimage() is used to create a subimage for the damaged area, which
is converted to native format if necessary.
Signed-off-by: Ian Scott ian.sc...@arteris.com
---
hw/kdrive/ephyr/hostx.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c
index dc265d5..3914f73 100644
--- a/hw/kdrive/ephyr/hostx.c
+++ b/hw/kdrive/ephyr/hostx.c
@@ -1039,11 +1039,13 @@ hostx_paint_rect(KdScreenInfo *screen,
sx, sy, dx, dy, width, height, FALSE);
}
else {
-/* This is slow and could be done better */
This comment is still valid. :(
xcb_image_subimage() does a very slow (get_pixel/put_pixel) copy even
when it could just create a view in the native case.
-xcb_image_t *img = xcb_image_native (HostX.conn, scrpriv-ximg, 1);
-xcb_image_put(HostX.conn, scrpriv-win, HostX.gc, img, 0, 0, 0);
-if (scrpriv-ximg != img)
+xcb_image_t *subimg = xcb_image_subimage(scrpriv-ximg, sx, sy,
+ width, height, 0, 0, 0);
+xcb_image_t *img = xcb_image_native(HostX.conn, subimg, 1);
+xcb_image_put(HostX.conn, scrpriv-win, HostX.gc, img, dx, dy, 0);
+if (subimg != img)
xcb_image_destroy(img);
+xcb_image_destroy(subimg);
Nevertheless,
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-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
[xrandr 1/2] Mark disabling an output as a change in its CRTC
When an output is disabled via the cmdline, we can use that information
to prevent assigning the current CRTC to the output and free it up for
reuse by other outputs in the first pass of picking CRTC.
Reported-and-tested-by: Nathan Schulte nmschu...@gmail.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
xrandr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xrandr.c b/xrandr.c
index fbfd93e..c0feac3 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -3029,7 +3029,7 @@ main (int argc, char **argv)
if (!config_output) argerr (%s must be used after --output\n,
argv[i]);
set_name_xid (config_output-mode, None);
set_name_xid (config_output-crtc, None);
- config_output-changes |= changes_mode;
+ config_output-changes |= changes_mode | changes_crtc;
continue;
}
if (!strcmp (--fb, argv[i])) {
--
2.1.4
___
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
[xrandr 2/2] Mark all CRTC as currently unused for second picking CRTC pass
We perform two passes over the CRTC in order to find the preferred CRTC
for each enabled output. In the first pass, we try to preserve the
existing output - CRTC relationships (to avoid unnecessary flicker).
If that pass fails, we try again but with all outputs first disabled.
However, the logic to preserve an active CRTC was not disabled along
with the outputs - meaning that if one was active but its associated
output was disabled by the user, then that CRTC would remain unavailable
for other outputs. The result would be that we would try to assign more
CRTC than available (i.e. if the user request 3 new HDMI outputs on a
system with only 3 CRTC, and wished to switch off an active internal
panel, we would report cannot find CRTC even though that configuration
could be established.)
Reported-and-tested-by: Nathan Schulte nmschu...@gmail.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
xrandr.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/xrandr.c b/xrandr.c
index c0feac3..181c76e 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -2243,6 +2243,8 @@ static void
pick_crtcs (void)
{
output_t *output;
+int saved_crtc_noutput[num_crtcs];
+int n;
/*
* First try to match up newly enabled outputs with spare crtcs
@@ -2274,7 +2276,18 @@ pick_crtcs (void)
*/
for (output = all_outputs; output; output = output-next)
output-current_crtc_info = output-crtc_info;
+
+/* Mark all CRTC as currently unused */
+for (n = 0; n num_crtcs; n++) {
+ saved_crtc_noutput[n] = crtcs[n].crtc_info-noutput;
+ crtcs[n].crtc_info-noutput = 0;
+}
+
pick_crtcs_score (all_outputs);
+
+for (n = 0; n num_crtcs; n++)
+ crtcs[n].crtc_info-noutput = saved_crtc_noutput[n];
+
for (output = all_outputs; output; output = output-next)
{
if (output-mode_info !output-crtc_info)
--
2.1.4
___
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/6] prime: add rotation support for offloaded outputs
On Mon, Jun 15, 2015 at 09:25:01AM +1000, Dave Airlie wrote: One of the lacking features with output offloading was that screen rotation didn't work at all. This patch makes 0/90/180/270 rotation work with USB output and GPU outputs. When it allocates the shared pixmap it allocates it rotated, and any updates to the shared pixmap are done using a composite path that does the rotation. The slave GPU then doesn't need to know about the rotation and just displays the pixmap. This doesn't seem right. The slaved output already has the transform details and currently the ability to apply HW transformation when possible. It also needs to know the transform for applying the HW cursor. I guess the problem you face is that you want the host GPU to accelerate the rotation for a slaved USB device? -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 1/2] atom: Bump initial table size
On Fri, Jun 05, 2015 at 10:26:15AM -0400, Adam Jackson wrote: On Tue, 2015-06-02 at 20:54 +0100, Chris Wilson wrote: On Tue, Jun 02, 2015 at 02:08:38PM -0400, Adam Jackson wrote: We're always creating ~230 atoms at startup, might as well tune it so we don't hit the realloc path before Dispatch. Any clue as to how you found out this figure? dmt:~% Xvfb -ac -terminate -fp built-ins :1 [1] 31760 dmt:~% DISPLAY=:1 xlsatoms | wc -l 233 Thank you, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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
