Re: Slow XQueryPointer?
On Thu, 2012-01-26 at 15:22 +0200, Lauri Kasanen wrote: Hi list Tracing why there's the occasional delay in Irrlicht apps showed the culprit as XQueryPointer. It's called once per frame, but occasionally it takes much longer than the average 80us - up to 30ms. This is a huge delay and easily noticable as a skip/jitter. Trying various alternatives, like using the mouse position from the last Motion/Click event proved jerky/jittery and seemed to lag the mouse by some frames. Any suggestions on making the call faster? Would it be possible to use it with a timeout, say, if it takes over 1ms, abort? Xlib doesn't work that way. You could do that with XCB and a main loop though. I'd suspect one of two scenarios. Either the X server has some periodic work it's doing, or the kernel's not waking up X promptly enough. Both should be fairly easy to work through. In the former case, it's most likely to be something on the WakeupHandler or BlockHandler call chains in the X server, which run on either side of the call to select() in the main loop. Probably the easiest way to see what's going on is to have your app print timestamps when it calls QueryPointer, and 'strace -t -e file' on the X server (from an ssh session into the machine under test). Then compare. If there's a long lag between your call to QueryPointer to the X server waking up from select and handling it, then the kernel's not getting the message across in time. If there's a lag between the server waking up and writing back the response, then the server's doing excess work. If it's a server issue we'd need to know what driver and hardware you're using. - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Slow XQueryPointer?
On Thu, 2012-01-26 at 11:58 -0500, Adam Jackson wrote: I think a more complete solution would involve changing the main loop's logic slightly: if we get to the end of requests for a single client within a single timeslice, start pulling requests from any other clients that have pending requests (in priority order) until the timeslice expires (at which point we'd loop back around to select and start again). This would punish absolute throughput for any one client when contended, but I'm willing to take that if it means we stop dropping frames. Just a quick followup since it was an easy experiment to run. Test machine: model name : Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz The reproducer scenario is two apps, one that's throughput-bound and one that's latency-bound. Easiest way to get this is one x11perf -noop and one x11perf -pointer. With the stock tuning on an idle server, -noop performance is about 21.6e6 per second, and -pointer is about 28.7e3 per second. With both running at once, -noop performance is essentially unchanged but -pointer drops to a mere 1.02e3/s. If I change the default timeslice to 2ms (and the max to 16ms, not that this case would hit it), baseline performance is unchanged. Running both -noop and -pointer at once, -noop drops to about 20.6e6/s but -pointer climbs to 3.8e3/s. So, there's that. You lose about 5% in the pathologically throughput-bound case, but your peak latency goes way down. Sounds like a no-brainer to me, honestly. And I'm pretty sure if you wanted that 5% back that the other code change I proposed would recover it. - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Slow XQueryPointer?
On Thu, 2012-01-26 at 19:34 +0200, Lauri Kasanen wrote: Hi ajax Thanks for taking the time to look into this. Trying -schedInterval 5 had slight improvement - the skips weren't as high, the highest was 7ms. But the skips still happen about just as often. That's about what I'd expect. The worst-case latency with the current algorithm is linear [1] on the number of clients you're contending with, so you're still going to see latencies greater than the timeslice if you have more than one other app to compete with. This sounds good. Could this make it to the next xserver release? Well, we can try. Certainly tuning the defaults would be an improvement even if we don't fix the algorithm. I don't know if I'll have a better algorithm for 1.12.0 but it should be easy to backport whenever it gets written. Also, even when this is fixed, there's going to be many linux systems without it for a year or two. Would there be any workaround for affected systems my app could do? Simplest thing (although kind of hideous) might be to launch another thread with its own Display connection and only ever run XQueryPointer from that, save the coordinates in some shared variable protected by a mutex, and read from that in the main thread. Or in a separate process over a pipe, if you don't like threads. I don't really know what you need the result for, though, so I don't know if that's a viable technique for you. [1] - Not actually sure it's not worse than that, tbh. I suspect there's ways you could end up starved forever with no more than two other clients (and without even going into the sync extension's priority levels). - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: High CPU usage with tabs and GTK
On Fri, 2012-02-24 at 23:40 -0800, Neil Whelchel wrote: Here is a cut and paste of what strace shows, the messages repeat about 90 times per second when tabs are active. strace output is unpleasantly difficult to read for this purpose. Try using xscope instead: http://cgit.freedesktop.org/xorg/app/xscope/ - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xfs 1.1.2
On 3/2/12 9:39 AM, Andreas Radke wrote: FTBS here ar ArchLinux: make[2]: Entering directory `/build/src/xfs-1.1.2' CC atom.o CC cache.o CC charinfo.o In file included from difs/charinfo.c:66:0: ./include/difs.h:45:13: error: conflicting types for 'MakeAtom' /usr/include/X11/fonts/fontmisc.h:55:13: note: previous declaration of 'MakeAtom' was here ./include/difs.h:46:12: warning: redundant redeclaration of 'ValidAtom' [-Wredundant-decls] /usr/include/X11/fonts/fontmisc.h:56:12: note: previous declaration of 'ValidAtom' was here ./include/difs.h:47:15: warning: redundant redeclaration of 'NameForAtom' [-Wredundant-decls] /usr/include/X11/fonts/fontmisc.h:57:14: note: previous declaration of 'NameForAtom' was here make[2]: *** [charinfo.o] Error 1 make[2]: Leaving directory `/build/src/xfs-1.1.2' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/src/xfs-1.1.2' make: *** [all] Error 2 Yeah, needs a newer libXfont release, by which I mean, libXfont needs a release. - ajax ___ 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: arch...@mail-archive.com
Re: XDrawLine and optimization
On 3/2/12 4:21 PM, Christopher Howard wrote: I don't have much (any?) Xlib programming savvy, but before diving headlong into the Programming Manual I was hoping to get some perspective. There is a particular application I use pretty often, and one of the things it does is to draw filled line graphs on the screen, which it does by calling XDrawLine() with the appropriate parameters for each data point. Looking at the code, I was curious if I could optimize this, by first drawing everything into some kind of local memory buffer and then passing that into some Xlib function all at once. However, since XDrawLine() presumably draws the lines into a buffer anyway, I'm wondering if there are any realistic gains (or any gains at all) to be had by such an approach. Might or might not help. It really depends more what kind of lines you're drawing - in particular what the GC state is you're using to draw them and the characteristics of the surface you're drawing to - and which driver you're using. Can you give more detail? - ajax ___ 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: arch...@mail-archive.com
Re: x forwarding?
On Wed, 2012-03-14 at 03:27 -0400, gene heskett wrote: ssh -Y first machine works, and uses Display:10:0, ssh -Y second machine doesn't, tries fails to use Display 0:0. Where what does it take to enable the 2nd one? (not normally at the same time) Either: a) The shell you launched ssh from for the second machine didn't have $DISPLAY set, b) sshd_config for the second machine doesn't have X11Forwarding yes in it. - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XShmQueryExtension, valgrind and a still reachable block.
On 3/16/12 12:19 PM, Antonio Ospite wrote: ==27577== 24 bytes in 1 blocks are still reachable in loss record 1 of 1 ==27577==at 0x402894D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==27577==by 0x4A30AFD: XextCreateExtension (in /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0) ==27577==by 0x4A305A4: ??? (in /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0) ==27577==by 0x4A3091C: ??? (in /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0) ==27577==by 0x4A30D31: XextAddDisplay (in /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0) ==27577==by 0x4A2B5B8: XShmQueryExtension (in /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0) ==27577==by 0x4006D5: main (in /home/ao2/WIP/am7xxx-play/tests/XShmQueryExtension_test) ... Maybe this is intended and not an actual bug, but I wanted to ask here for confirmation. So, is this message OK or a symptom of an actual bug? It's a bug if you expect your program to survive disconnecting from the X server, but most people don't expect that to be a thing. That said, I'm unable to reproduce this on Fedora 16 (libX11 1.4.3 and libXext 1.2.0). What OS are you seeing this on, and what versions of those packages does it have? - ajax ___ 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: arch...@mail-archive.com
Re: VESA driver
On Thu, 2012-03-22 at 13:38 +0100, Henrik Pauli wrote: it appears to me that xorg-driver-vesa-2.3.0 does not compile with the latest X, and it hasn't been updated since 2010. Are there any plans to release a new version or is there another driver that should be used instead as a generic fallback? The version in git works fine. Fair point though, I'll release a new one later today. - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-video-vesa 2.3.1
Minor maintenance release for xserver 1.12. Adam Jackson (4): Refuse to load if there's a kernel driver bound to the device Fix memory leak in mode validation Be forgiving of character-cell size mismatches in mode sizes vesa 2.3.1 Alan Coopersmith (1): Update Sun license notices to current X.Org standard form Gaetan Nadon (10): config: Move compiler flags from configure.ac to Makefile.am COPYING: update file with Copyright notices from source code. config: upgrade to util-macros 1.8 for additional man page support config: update AC_PREREQ statement to 2.60 config: remove AC_PROG_CC as it overrides AC_PROG_C_C99 config: remove unrequired AC_HEADER_STDC config: complete AC_INIT m4 quoting config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: replace deprecated use of AC_OUTPUT with AC_CONFIG_FILES config: add comments for main statements Jeremy Huddleston (5): Build fix for ABI Version 12 Use unsigned long rather than deprecated IOADDRESS Build fix for ABI Version 12 Code style cleanup to make the map and unmap blocks more consistent configure.ac: Require a newer version of libpciaccess Jesse Adkins (1): Purge cvs tags. Trevor Woerner (1): Convert x+m/calloc/free to m/calloc/free. git tag: xf86-video-vesa-2.3.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.3.1.tar.bz2 MD5: 02e6eacc2d1e07ac893b62481905d6f0 xf86-video-vesa-2.3.1.tar.bz2 SHA1: acb4f8104f16476d46ceb366aa932783c3644ead xf86-video-vesa-2.3.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.3.1.tar.gz MD5: 6d37aaab9957d41e49934eb1a4055310 xf86-video-vesa-2.3.1.tar.gz SHA1: 4a974359033c3193b088e95ffe82cdbc10937f38 xf86-video-vesa-2.3.1.tar.gz - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Randr window resize
On Fri, 2012-05-18 at 09:19 +0200, Eirik Byrkjeflot Anonsen wrote: Adam Jackson a...@redhat.com writes: On 5/17/12 1:33 PM, g4hx wrote: To my knowledge, this is not possible with Xorg at the moment. Correct me if I am wrong, but I think that this is a problem with the X server and not the GUI toolkits like Qt or Gtk+. You are wrong. RANDR sends events for this kind of change. If the toolkit isn't picking them up that's a toolkit bug, although I would have thought they already do. I would have expected that to be primarily the window manager's job. Sure, why not. My point was mostly that the events do happen, so wherever the bug is it's not in the server. - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XSetBackgroundPixmap question
On Sat, 2012-05-19 at 23:00 +0100, Glynn Clements wrote: I've encountered code which uses a background pixmap to implement a persistent screen, and drawing to the pixmap then calling XClearWindow (without calling XSetWindowBackgroundPixmap in between) results in the updated pixmap contents appearing in the window. So it appears to use reference counting or similar. Any code which does this is being inadvisably friendly with the implementation. From the protocol spec: Subsequent drawing into the background or border pixmap has an undefined effect on the window state. The server might or might not make a copy of the pixmap. The sample implementation (at least at the dix level) has always done the current behaviour of taking a reference on the pixmap, but the sample implementation is not the only X server ever written. - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Image depth, visuals and colormaps
On 5/30/12 4:32 AM, Alexandre CONFIANT-LATOUR wrote: What are the good practices for getting on the fly color depth switching to work ? That's not a thing xserver is set up to do, because that's not a thing X lets you do. The list of depths is constructed statically at server startup, and the only way to get the list of depths and visuals is in the initial connection handshake; which means it doesn't happen, because clients are not written to disconnect and reconnect. You could probably hack something into working, but. A much easier thing to do would be to simply export multiple _screens_ from the same display, each with a different depth, and then run your rendering against the screen with the depth you want instead of trying to switch the depth of a single screen. - ajax ___ 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: arch...@mail-archive.com
Re: Why is XSetStandardProperties freezing?
On Thu, 2012-06-14 at 13:52 +0100, Myrosia Dzikovska wrote: Hi, I have a program using an X graphics library that works on FC 13 and ScientificLinux 6, but freezes on OpenSuse 12.1. I need to get it running, and I am trying to determine the cause of failure. I'm not an X developer, and because the library is complex, I am struggling to come up with a minimal example. The specific cause of the problem is the call in the code: XSetStandardProperties(win-theDisp, win-theWindow, wname, hgraf, None, NULL, 0, (win-hints)); I verified by putting print statements around it that it never returns, the program freezes there. The initialization code is complex, but the best I can tell it boils down to char *hgraf = HGraf; win-theDisp = XOpenDisplay(0) win-theScreen=DefaultScreen(win-theDisp); win-rootW=RootWindow(win-theDisp, win-theScreen); win-theWindow = XCreateSimpleWindow(win-theDisp, win-rootW, x, y, w, h, bw, black, white ); I am at a loss as to what I should be checking here, and what could cause the program to hang at that XSetStandardProperties call, with no error messages or exceptions. How can I debug this? I would probably start by calling XSynchronize(dpy, 1) just after XOpenDisplay, to see if that changes where the hang happens. Another strategy would be to compare the generated X protocol between the OSes that work and the ones that don't. You can use wireshark for this if you set DISPLAY=localhost:0 (and didn't start your X server with -nolisten tcp); alternatively, there's xscope(1). Are you using the same window manager across all systems? If not, that's a pretty likely place to start looking. - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Odd behavior with damage events and override-redirect windows
On 7/16/12 5:27 PM, Jess VanDerwalker wrote: This works correctly for non-override redirect windows. But something odd occurs with window flagged as override redirect. In that case, the coordinates for the window are root relative, not window relative. As an example, if the override redirect window is mapped with x=10, y=10, width=100, height=100 the first damage event (which is a complete drawing of the window) would report a damage area of x=10, y=10, width=100, height=100. I've seen a couple of bugs that I think could be related. If you can reproduce this without a compositing manager, I'd be interested to know whether either or both of: a) an X server started with '-extension Composite' b) an X server built with --disable-composite do _not_ have this bug. - ajax ___ 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: arch...@mail-archive.com
Re: vesa_drv compatibility question
On 7/22/12 5:38 AM, soul wrote: SUPPORTED HARDWARE The vesa driver supports most VESA-compatible video cards. There are some known exceptions, and those should be listed here. Is there a list of such known exceptions? That is, VESA-compatible cards which are known NOT to work at all or well enough with this driver? I don't know of such a list. Possibly one existed when that man page was written. Secondly, in more general terms, how likely is it to find Laptops (especially), or PC/monitor combinations which are NOT VESA-compatible? Right now, the odds of that are close to zero. In about a year or two, for new hardware, those odds are going to be much closer to one. The UEFI transition is going to mean that the vesa driver will no longer work. Why do you ask? - ajax ___ 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: arch...@mail-archive.com
Re: E-EDID support: read out extension blocks
On 8/14/12 9:47 AM, Christophe Oosterlynck wrote: Hi all, to be HDMI compliant, extension blocks provided by E-EDID should be read out. It seems that X doesn't do this. I've been browsing through the code and found a commit [1] which introduced the 'complete' parameter to xf86DoEEDID. This is being called with complete=FALSE from xf86DoEDID_DDC2 [2]. I was wondering why and if there is any other code path where this function is called with complete=TRUE? Or doesn't X support reading out extensions blocks by default and can it only be done by calling xf86DoEEDID myself? ... which the X drivers do, yes. What bit of HDMI compliance do you think we're missing here? All drivers that actually support the bits of HDMI beyond plain DVI have kernel support, and Linux does parse the HDMI extension block. - ajax ___ 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: arch...@mail-archive.com
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.20.6
On 9/2/12 5:40 AM, Chris Wilson wrote: * Incoherent concurrent access with the CPU and GPU https://bugs.freedesktop.org/show_bug.cgi https://bugs.freedesktop.org/show_bug.cgi Which bugs were these meant to be? - ajax ___ 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: arch...@mail-archive.com
Re: Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
On 9/22/12 5:55 PM, Robert Heller wrote: First of all, using the VGA connection, the X server *refuses* to use any Modeline that is not a 4:3 aspect ratio. It seems that the X server presumes that *all* VGA connected monitors are 4:3. (All three of the new wide screen monitors do have 15-pin VGA connections, so this 'presumption' is obviously false, esp. since the monitors using DDC while connection via VGA are suggesting 16:9 mode lines.) It's not the X server's fault. The i810 driver, when it comes to output setup, is no better than the vesa driver. It can only set modes that happen to be listed in the video BIOS, regardless of what the display happens to claim to support. Since most 845 video BIOSes predate the wide availability of 16:9 monitors, they naturally tend not to list any 16:9 modes. RHEL5 (and therefore CentOS 5) does include an additional video driver for Intel graphics chips called 'intel' instead of 'i810', which does not have this limitation. I don't recall offhand whether that version worked correctly with 8xx-series chips; it might, I don't think I went out of my way to disable that, but if it doesn't work you get to keep both pieces. Alternatively, go search for 'i915resolution', which will allow you to override Intel VBIOS mode lists (and yes it does work on 8xx chips despite the name). - ajax ___ 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: arch...@mail-archive.com
Re: Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
On Mon, 2012-09-24 at 15:31 -0400, Robert Heller wrote: If hostname is longer than 33 characers, the server can't locate/open the config file. I'm guessing someone is using a fixed size buffer (#1 nono!) that is not big enough. Yes, some of use use long and meaningful domain and host names... The hostname buffer is a fixed length anyway, see man gethostname. But that you're seeing truncation to 33 bytes is certainly a server bug, I think the MAXHOSTNAMELEN code in hw/xfree86/parser/scan.c should just be talking about HOST_NAME_MAX like the gethostname man page suggests. - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Dell D520 and strange X coordinates
On 10/30/12 8:36 AM, Michael George wrote: On Sun, Oct 14, 2012 at 02:59:27PM +0200, Thomas L?bking wrote: What's the output of xrandr -q? This is the output of xrandr -q with ctwm running: - Screen 0: minimum 320 x 200, current 3584 x 1024, maximum 4096 x 4096 LVDS1 connected (normal left inverted right x axis y axis) 1024x768 60.0 + 800x60060.3 56.2 640x48059.9 VGA1 connected 1280x1024+1024+0 (normal left inverted right x axis y axis) 376mm x 301mm See, this here is saying 1280x1024 box, horizontal offset 1024, vertical offset 0. How are you configuring this display? Are you just letting xserver decide how to place things, or is there something in your session explicitly configuring RANDR? If the latter, whatever it is, it's broken. - ajax ___ 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: arch...@mail-archive.com
Re: Can't hook into the Double Buffer extension.
On Fri, 2014-09-12 at 14:59 -0400, Stirling Westrup wrote: I am writing a video driver for which I'd like to support the Double Buffer Extension. However I need to hook some of the calling functions described xorg/dbestruct.h, especially 'AllocateBackBuffer' and 'SwapBuffers'. You found an app that uses it? Impressive. However, the only way to access them is via the private key for dbe, and its not exported. Am I missing something, or is it really impossible to hook those functions? At the moment, yeah. Not so much out of malice as neglect, the extension is not widely used and none of the open (or closed!) drivers attempts to support it specially. I wouldn't object to a patch, although I'd at least like to see it done with accessor functions that return the window/screen private pointer rather than by exporting the private keys. Ideally we'd do what the GLX spec says and unify the view of the back buffer across extensions, which I guess could include DRI3 at this point. - ajax ___ 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
[ANNOUNCE] xf86-video-mach64 6.9.5
Adam Jackson (3): preinit: Don't bother explicitly loading int10, vbe will do it for us Bump minimum xserver to 1.4 mach64 6.9.5 Alan Coopersmith (2): Remove unused atidecoder.c atidecoder.h Remove unused atiaudio.c ATIAudioNames declaration Connor Behan (1): Drop dependence on xf86PciInfo.h Dave Airlie (1): mach64: fix build probably not required with pci access anyways Matthieu Herrb (1): Deal with pPict-pDrawable == NULL for source-only pictures. git tag: xf86-video-mach64-6.9.5 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-mach64-6.9.5.tar.bz2 MD5: 1013ccc86052d0e82c4d504e0c4e896e xf86-video-mach64-6.9.5.tar.bz2 SHA1: 0ba2d51752a62808286937cf3c6a95794fa5cb29 xf86-video-mach64-6.9.5.tar.bz2 SHA256: 3e98985b6e044189efd42342862208f472881c25debf22230a1d54a96d71b41f xf86-video-mach64-6.9.5.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-mach64-6.9.5.tar.gz MD5: 4864011b2ec48849aaea78c05536eedb xf86-video-mach64-6.9.5.tar.gz SHA1: 5fe451f4f26aecc765f4237cca5e578dd0e9387d xf86-video-mach64-6.9.5.tar.gz SHA256: 38672f863f4a08c20f30c248555e12dca38fc25793af5214b9e229e6c4fa460d xf86-video-mach64-6.9.5.tar.gz - ajax ___ 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
[ANNOUNCE] xorg-server 1.17.2
This picks up a pile of fixes from master. Notable highlights: - Fix for CVE-2015-3164 in Xwayland - Fix int10 setup for vesa - Fix regression in server-interpreted auth - Fix fb setup on big-endian CPUs - Build fix for for gcc5 Complete changelog: Aaron Plattner (2): xfree86: Fix xf86_check_platform_slot's handling of PCI xfree86: Add GPU screens even if there are no active GDevs Adam Jackson (1): xserver 1.17.2 Adel Gadllah (1): modesetting: Fix software cursor fallback Alan Coopersmith (2): Clear ListenTransConns entries in CloseWellKnownConnections Accept x86_64 as well as i*86 for $host_cpu in Solaris on x86 Brent Collins (1): shm: Fix xselinux resource initialization for xinerama pixmaps Chris Wilson (2): shm: Fix use-after-free in ShmDestroyPixmap present: Copy unflip contents back to the Screen Pixmap Colin Harrison (2): os/xdmcp.c: Include Xtrans.h when building for WIN32 os/utils.c: Don't try to build os_move_fd() for WIN32 Dave Airlie (2): os/access: fix regression in server interpreted auth glamor: don't do render ops with matching source/dest (v2) Dima Ryazanov (1): xwayland: Implement smooth scrolling Egbert Eich (6): symbols: Fix sdksyms.sh to cope with gcc5 Xephyr: Don't crash when no command line argument is specified Xephyr: Print default server display number if none is specified Xephyr: Fix compile when debugging is enabled Xephyr: Fix screen image draw for the non-Glamor non-XHSM case Xephyr: Fix broken image when endianess of client machine and host-Xserver differ Emil Velikov (2): randr: remove chatty error messages randr: use randr: prefix in ErrorF() Hans de Goede (1): Re-enable non serverfd input devices immediately on vtenter Jason Gerecke (2): xfree86: Return NULL from xf86CompatOutput if no compat_output is defined dix: Do not allow device transform to be set on valuatorless devices Jon TURNEY (9): ephyr: Avoid a segfault with 'DISPLAY= Xephy -glamor' os: XDMCP options like -query etc. should imply -listen tcp os: Teach vpnprintf() how to handle %*.*s hw/xwin/glx: Refactor parsing of the proto XML element hw/xwin/glx: Improve code generator to deal with latest Khronos OpenGL registry XML hw/xwin: Report Cygwin version information in log glamor: Fix build when configured --enable-glamor --disable-xshmfence hw/xwin/winclipboard: Link xwinclip with -lpthread hw/xnest: Fix build for MinGW Jonathan Gray (2): glamor: remove const from the return type of glamor_get_drawable_location() glamor: fix build when DRI3 is not defined Jürg Billeter (1): int10: Fix error check for pci_device_map_legacy Keith Packard (1): mi: Partial pie-slice filled arcs may need more space for spans Maarten Lankhorst (4): glamor: only use (un)pack_subimage when available glamor: do not check for gl errors in glamor_build_program glamor: Use GL_FRAMEBUFFER instead of GL_READ_FRAMEBUFFER glamor: GL_TEXTURE_MAX_LEVEL is not available on GLES2 Michal Srb (1): Expose GetMaster to modules. Michel Dänzer (2): Add AC_SYS_LARGEFILE defines to dix-config.h modesetting: Include dix-config.h from dumb_bo.c Olivier Fourdan (4): ephyr: Fail if glamor is requested but not usable xwayland: Add dependency on glamor libs glamor: check max native ALU instructions dix: Fix image byte order on big endian hardware Ray Strode (5): systemd-logind: filter out non-signal messages from message filter systemd-logind: don't second guess D-Bus default timeout xwayland: Enable access control on open sockets [CVE-2015-3164 1/3] os: support new implicit local user access mode [CVE-2015-3164 2/3] xwayland: default to local user if no xauth file given. [CVE-2015-3164 3/3] Robert Ancell (1): xwayland: Fix error strings Rui Matos (2): dix/events: Set currentTime to the given time stamp in NoticeTime xwayland: Throttle our cursor surface updates with a frame callback Vicente Olivert Riera (1): backtrace.c: Fix word cast to a pointer git tag: xorg-server-1.17.2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.17.2.tar.bz2 MD5: 397e405566651150490ff493e463f1ad xorg-server-1.17.2.tar.bz2 SHA1: 56ac29a82b99bcf4c7ba2fca41a44cfa18748262 xorg-server-1.17.2.tar.bz2 SHA256: f61120612728f2c5034671d0ca3e2273438c60aba93b3dda4a8aa40e6a257993 xorg-server-1.17.2.tar.bz2 PGP: http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.17.2.tar.bz2.sig http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.17.2.tar.gz MD5: 01012da00e2d76a305bd3e522c9583cf xorg-server-1.17.2.tar.gz SHA1: e71f5634ab1adf6b5017e21d1432d50f70e6c405 xorg-server-1.17.2.tar.gz SHA256: fc568544920e9872fa615db3e32c8930e739dbef8b20366e775dee42db8ff5d1 xorg
[ANNOUNCE] xorg-server 1.17.4
Minor brown-bag release. The important fix here is Martin's clientsWritable change which fixes a crash when built against xproto 7.0.28. Adam Jackson (1): xserver 1.17.4 Julien Cristau (1): Xext: fix build with --disable-xace Martin Peres (1): os: make sure the clientsWritable fd_set is initialized before use Michel Dänzer (1): DRI2: Sync radeonsi_pci_ids.h from Mesa git tag: xorg-server-1.17.4 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.17.4.tar.bz2 MD5: 1509a9daae713895e7f5bcba8bcc05b2 xorg-server-1.17.4.tar.bz2 SHA1: 139c4d6795eb4c3848616cc514d134532975e49e xorg-server-1.17.4.tar.bz2 SHA256: 0c4b45c116a812a996eb432d8508cf26c2ec8c3916ff2a50781796882f8d6457 xorg-server-1.17.4.tar.bz2 PGP: http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.17.4.tar.bz2.sig http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.17.4.tar.gz MD5: e153561abccca3b83b9ccf6a0b110be7 xorg-server-1.17.4.tar.gz SHA1: d5117fbe296caf16b96d62805b5fa655f6126d18 xorg-server-1.17.4.tar.gz SHA256: 73208283875dc7f02c66546f8d83fe2e70ffc6d639c9394b8754d2edcbff6e2f xorg-server-1.17.4.tar.gz PGP: http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.17.4.tar.gz.sig - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[ANNOUNCE] xorg-server 1.17.3
Various bugfixes across the board. The most visible changes include fixing GLX extension setup under Xwayland and other non-Xorg servers (enabling core contexts in more scenarios), and various stability fixes to glamor and the Present extension. Full change list: Aaron Plattner (1): privates: Clear screen-specific keys during CloseScreen Adam Jackson (9): fb: Make rootless-agnostic glx/swrast: Do more GLX extension setup glx: Implement GLX_ARB_context_flush_control xwayland: Don't (double) destroy RANDR resources in CloseScreen xwayland: Don't (double) destroy input resources in CloseScreen glxproxy: Fix an obvious thinko in QueryExtensionsString render: Simplify SProcRenderScale rootless: Fix bogus handling of broken root clip xserver 1.17.3 Alan Coopersmith (20): Get rid of const warnings in XSERVER_INPUT_EVENT dtrace probe calls dmx: Add _X_ATTRIBUTE_PRINTF to dmxConfigLog() & dmxConfigOutput() dmx: move format strings inline so gcc can check dmx: fix printf format argument warnings dmx: remove unused variables dmx: attempt to untangle nested loops using same index variable dmx: more unshadowing of variables dmx: glxproxy prototype cleanup dmx: remove redundant declaration of dmxFontPrivateIndex from dmxfont.h dmx: remove redundant redeclarations of variables from other headers dmx: Mark glxIsExtensionSupported as a const char * dmx: constify GCOps & GCFuncs pointers dmx: include header for DMXExtensionInit() in dmx.c Xserver.man: -retro is used when starting the server, not the stipple Remove DECnet from Xserver.man protocol.txt: Remove extensions that died before Xorg was born protocol.txt: Add Present 1.0 requests protocol.txt: Add DRI3 1.0 requests protocol.txt: Add MIT-SHM 1.2 requests dri2: better checks for integer overflow in GetBuffers* Andrea Canciani (1): render: Allow single-stop gradients Andrew Eikum (2): xace: Add XaceHookIsSet helper function dix: Send KeyPress and KeyRelease events to the XACE_KEY_AVAIL hook Arcady Goldmints-Orlov (1): Fix alphamap interactions with wfb Chris Wilson (4): randr/prime: Don't stop on the first pipe when disabling ReplaceScanoutPixmap render: Fix leak of filter params render: Propagate allocation failure from createSourcePicture() present: Fix missed notify MSC computation Cyril Brulebois (1): man: Fix case for MIT-unspecified. Daniel Drake (2): Allow system call restarts upon signal interruption Keep SIGALRM restart flag after Popen Dave Airlie (5): glamor: make current in prepare paths glx: fix regression with copy sub buffer disappearing rootless: fix warnings due to lack of const keeping. rootless: rename w->_w to avoid shadow warnings exa: initialise mask_off_x and mask_off_y Egbert Eich (1): randr: Remove senseless checks for xf86RandR12Key Eric Anholt (2): glamor: Don't try to free the pixmap priv if we fail to allocate FBO. x86emu: Fix some set-but-not-used warnings. Felix Janda (1): On linux use instead of Fredrik Höglund (1): present: Don't stash the MSC value when present_get_ust_msc fails Hans de Goede (1): linux: Do not call FatalError from xf86CloseConsole Ian Scott (1): Xephyr: Paint with subimage for non-Glamor & non-XSHM case Ingo Schwarze (1): remove bogus \/ escapes Jeremy Huddleston (5): mi: Correct a miscall of abs() to instead call fabs() randr: Correct a miscall of abs() to instead call fabs() xdmauth: Correct miscall of abs() to instrad call labs() xdmcp: Declare XdmcpFatal _X_NORETURN glx: Fix header length error checking in __glXDisp_RenderLarge Jeremy Huddleston Sequoia (9): XQuartz: GLX: Use __glXEnableExtension to build extensions list XQuartz: Silence -Wpointer-bool-conversion XQuartz: Silence -Wunused-variable XQuartz: Silence -Wunused-function XQuartz: Silence -Wformat-security for NSRunAlertPanel XQuartz: Relax App Transport Security for communicating with the update server XQuartz: Remove InfoPlist.strings XQuartz: Make sure that darwin_all_modifier_mask_additions is 0-terminated XQuartz: Cleanup formatting of DarwinEQInit that was butchered by automation a few years ago Julien Cristau (1): mi: fix typo in warning about overflowing queue Keith Packard (5): mi: Always initialize edge1 and edge2 in miLineArc os/xdmcp: Remove dead 'restart' code os/xdmcp: Just send XDMCP keepalive packets once every three minutes Xext/xselinux: Warning fixes fonts: Continue when font calls return Suspended more than once Ken Thomases (1): XQuartz: Fix how we calculate the height of the OSX menu bar Michal Srb (1): randr: Allow RRSelectInput for
[ANNOUNCE] xorg-server 1.17.99.902 (1.18 RC2)
Time for another release candidate. Long past time, to be honest. Please speak up soon if you have a favorite patch or series that isn't in yet. Aaron Plattner (1): privates: Clear screen-specific keys during CloseScreen Adam Jackson (6): glxproxy: Fix an obvious thinko in QueryExtensionsString render: Simplify SProcRenderScale rootless: Fix bogus handling of broken root clip composite: Factor out backing store transition xfree86: Use same inb/outb asm code for i386 amd64 and ia64 xserver 1.17.99.902 (1.18 RC2) Alan Coopersmith (9): Remove DECnet from Xserver.man Make configure test for LD_NO_UNDEFINED_FLAG on Solaris work w/autoconf 2.69 dri2: better checks for integer overflow in GetBuffers* protocol.txt: Remove extensions that died before Xorg was born protocol.txt: Add RANDR 1.5 requests protocol.txt: Add Present 1.0 requests protocol.txt: Add DRI3 1.0 requests protocol.txt: Add MIT-SHM 1.2 requests glamor: Get rid of an extraneous ; at the end of a C source line Alberto Milone (1): randr: make RROutputChanged change the main protocol screen not the gpu screen Alexandr Shadchin (2): xfree86: Remove 386BSD bsd: Remove LINKKIT Andrea Canciani (1): render: Allow single-stop gradients Andreas Wettstein (2): xkb: Suppress autorepeat for Set and Lock of Mods, Groups, and Controls xkb: Keyboard mouse button emulation should not suppress other keyboard events Andy Ritger (2): Remove static qualifier on mieqProcessInputEvents()'s 'event' mi: Log an error if mieqProcessInputEvents() recurses. Arcady Goldmints-Orlov (1): Fix alphamap interactions with wfb Boyan Ding (1): xwayland: Activate and enable device on first capability reporting Bryce Harrington (1): test: Fix typo and drop documentation references to glib. Carlos Garnacho (3): xwayland: Add xwl_touch struct xwayland: Implement the wl_touch interface xwayland: Remove related touchpoints when unrealizing windows Chris Wilson (5): randr/prime: Don't stop on the first pipe when disabling ReplaceScanoutPixmap render: Fix leak of filter params render: Propagate allocation failure from createSourcePicture() present: Fix missed notify MSC computation Xv: Only stop the adaptors when the Pixmap is finally destroyed Cyril Brulebois (9): man: Fix case for MIT-unspecified. doc: Get rid of RCS tags. doc: Fix typo. doc: Fix alignment. doc: Fix grammar and typos. doc: Fix extraneous doc: Fix punctuation. doc: Try to avoid repetitions. doc: Convert an \fP pair into appropriate tags. Daniel Drake (2): Allow system call restarts upon signal interruption Keep SIGALRM restart flag after Popen Dave Airlie (3): exa: initialise mask_off_x and mask_off_y glx: fix regression with copy sub buffer disappearing xf86: don't add gpus from udev if autoAddGPU is set Dima Ryazanov (3): xwayland: Remove a useless out-of-memory check xwayland: Destroy xwl_output when wl_output gets removed xwayland: Remove the output from the list after destroying it Egbert Eich (4): randr: Remove senseless checks for xf86RandR12Key fbdevhw: Disable FBIOBLANK ioctl if not supported libxf86config: Remove libxf86config: libxf86config_internal -> libxf86config Emil Velikov (3): glamor: explicitly check for GL_OES_EGL_image glamor: move GL_OES_EGL_image check next to EGL_EXT_image_dma_buf_import glamor: move 'dri3_capable' extension checks after eglMakeCurrent Eric Anholt (3): x86emu: Fix some set-but-not-used warnings. kdrive: Remove dead debug arrays. fbdevhw: Fix a const qualifier warning Felix Janda (1): On linux use instead of Fredrik Höglund (1): present: Don't stash the MSC value when present_get_ust_msc fails Gaetan Nadon (1): dmx: fix typo in the title Hans de Goede (1): linux: Do not call FatalError from xf86CloseConsole Ian Scott (1): Xephyr: Paint with subimage for non-Glamor & non-XSHM case Ilia Mirkin (1): modesetting: fix up output naming convention Ingo Schwarze (1): remove bogus \/ escapes Jamey Sharp (1): kdrive: Delete unused TOUCHSCREEN define. Jasper St. Pierre (2): xwayland-input: Remove our XYToWindow handler test/xi1: Update .gitignore Javier Jardón (1): configure.ac: Add support for new versions of systemd Jeremy Huddleston (10): mi: Correct a miscall of abs() to instead call fabs() randr: Correct a miscall of abs() to instead call fabs() xdmauth: Correct miscall of abs() to instrad call labs() xres: Silence -Wunused-function warnings when building !COMPOSITE or !RENDER security: Silence some benign -Wformat warnings xdmcp: Declare XdmcpFatal _X_NORETURN randr:
[ANNOUNCE] xf86-video-rendition 4.2.6
Just a few accumulated build fixes. Adam Jackson (4): Remove mibstore.h Fix build against xserver 1.17 Remove dependency on xf86PciInfo.h rendition 4.2.6 git tag: xf86-video-rendition-4.2.6 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-rendition-4.2.6.tar.bz2 MD5: 405dd1acba9c2e43d7aa67b631762495 xf86-video-rendition-4.2.6.tar.bz2 SHA1: b0c097890320be53ca678bd6f18de4c39e2409e8 xf86-video-rendition-4.2.6.tar.bz2 SHA256: 660ecf21f65a4d6002c1b603d62c314f8e9624d208db5b346850b0df9dc2f9a8 xf86-video-rendition-4.2.6.tar.bz2 PGP: http://xorg.freedesktop.org/archive/individual/driver/xf86-video-rendition-4.2.6.tar.bz2.sig http://xorg.freedesktop.org/archive/individual/driver/xf86-video-rendition-4.2.6.tar.gz MD5: 6702345c506bd1339dbc6a8d7235ca6e xf86-video-rendition-4.2.6.tar.gz SHA1: b7dfcd9a780902f7eeb08ab94f0963ddb15aafb2 xf86-video-rendition-4.2.6.tar.gz SHA256: 0da3dadfb18f335f53e88f33a6cfb5aa63d6775a63c01d60acd9953158d8c879 xf86-video-rendition-4.2.6.tar.gz PGP: http://xorg.freedesktop.org/archive/individual/driver/xf86-video-rendition-4.2.6.tar.gz.sig - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[ANNOUNCE] xorg-server 1.18.0
A few polish fixes here over RC2. I'll start the 1.18 stable branch and update master for 1.19pre in a moment. Thanks to everyone who helped make 1.18 our best release yet! Adam Jackson (3): build: Remove stale miext/cw include paths vidmode: Drop the unused event code xserver 1.18.0 Alan Coopersmith (3): Xorg.man: move XLOCAL details to X(7) man page instead Xorg.man: update to reflect -nolisten tcp becoming default Xserver.man: document more transports for -nolisten & -listen options Axel Davy (1): present: Fix Async swap logic Daniel Martin (3): modesetting: Handle failures in setting a CRTC to a DRM mode properly modesetting: Free output_ids in drmmode_set_mode_major() modesetting: Remove XF86_CRTC_VERSION checks Jammy Zhou (1): present: Execute right away if target_msc equals current_msc Julien Cristau (1): Xext: fix build with --disable-xace Martin Peres (1): os: make sure the clientsWritable fd_set is initialized before use Michel Dänzer (1): DRI2: Sync radeonsi_pci_ids.h from Mesa git tag: xorg-server-1.18.0 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.0.tar.bz2 MD5: 3c1c1057d3ad27380d8dd87ffcc182cd xorg-server-1.18.0.tar.bz2 SHA1: f37f9ca17d211552c775c3ce78ff03385026bf3a xorg-server-1.18.0.tar.bz2 SHA256: 195670819695d9cedd8dde95fbe069be0d0f488a77797a2d409f9f702daf312e xorg-server-1.18.0.tar.bz2 PGP: http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.0.tar.bz2.sig http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.0.tar.gz MD5: 926898a33c9ce4474a4868a166f57762 xorg-server-1.18.0.tar.gz SHA1: 721fbbcb2fd7a8b3ed9d370bd898779120541e4b xorg-server-1.18.0.tar.gz SHA256: a1bfa91ecbee765e3935dbb6a9204668ab84eb31a6978815c97ab6064585d71b xorg-server-1.18.0.tar.gz PGP: http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.0.tar.gz.sig - ajax ___ 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
[ANNOUNCE] xorg-server 1.18.0
(same message as before, except this one I remembered to gpg-sign) A few polish fixes here over RC2. I'll start the 1.18 stable branch and update master for 1.19pre in a moment. Thanks to everyone who helped make 1.18 our best release yet! Adam Jackson (3): build: Remove stale miext/cw include paths vidmode: Drop the unused event code xserver 1.18.0 Alan Coopersmith (3): Xorg.man: move XLOCAL details to X(7) man page instead Xorg.man: update to reflect -nolisten tcp becoming default Xserver.man: document more transports for -nolisten & -listen options Axel Davy (1): present: Fix Async swap logic Daniel Martin (3): modesetting: Handle failures in setting a CRTC to a DRM mode properly modesetting: Free output_ids in drmmode_set_mode_major() modesetting: Remove XF86_CRTC_VERSION checks Jammy Zhou (1): present: Execute right away if target_msc equals current_msc Julien Cristau (1): Xext: fix build with --disable-xace Martin Peres (1): os: make sure the clientsWritable fd_set is initialized before use Michel Dänzer (1): DRI2: Sync radeonsi_pci_ids.h from Mesa git tag: xorg-server-1.18.0 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18 .0.tar.bz2 MD5: 3c1c1057d3ad27380d8dd87ffcc182cd xorg-server-1.18.0.tar.bz2 SHA1: f37f9ca17d211552c775c3ce78ff03385026bf3a xorg-server- 1.18.0.tar.bz2 SHA256: 195670819695d9cedd8dde95fbe069be0d0f488a77797a2d409f9f702daf312e xorg- server-1.18.0.tar.bz2 PGP: http://xorg.freedesktop.org/archive/individual/xserver/xorg-serve r-1.18.0.tar.bz2.sig http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18 .0.tar.gz MD5: 926898a33c9ce4474a4868a166f57762 xorg-server-1.18.0.tar.gz SHA1: 721fbbcb2fd7a8b3ed9d370bd898779120541e4b xorg-server- 1.18.0.tar.gz SHA256: a1bfa91ecbee765e3935dbb6a9204668ab84eb31a6978815c97ab6064585d71b xorg- server-1.18.0.tar.gz PGP: http://xorg.freedesktop.org/archive/individual/xserver/xorg-serve r-1.18.0.tar.gz.sig - ajax 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: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Window does not receive expose events and therefore is not redrawn
On Wed, 2015-12-09 at 19:24 +0100, Marcus Reinhard wrote:
Standard disclaimer: coding to Xlib is for people who enjoy making
their lives hard, there's a reason we discourage it. But, since you
insist...
> To be more specific, the window is drawn correctly at first, but altough
> I see the lines in the terminal showing the mouse-/keyboard-input, the
> window itself is not redrawn,
I think you misunderstand what Expose events mean. They're generated
when the server has _lost_ the contents of the window, they're not just
generated for fun. You get one when the window is first mapped only
because the window doesn't have defined content yet. Your code here
doesn't redraw anything based on 'auswahl' unless it receives an Expose
event, and merely hitting an arrow key doesn't destroy the window
content so it's not going to generate an Expose.
You could fabricate one with XSendEvent if you wanted, I suppose, but
why ask the server to tell you to repaint when you could just do it
yourself. In this case, you'd factor everything from ClearWindow to the
final DrawLine into a repaint() function and call it whenever any
variable it depends on is modified.
> and if I force this by
> minimizing/restoring the window, the symbol (here a simple line) showing
> which section was selected with the arrow-keys, is not drawn except when
> the selection is back at the first section which is the default-selection...
This is just a math error. You're drawing long lines at y=75 and y=125,
and the short line at y={1,2,3} * 50 - 25, which works out to 25, 75,
and 125. So when auswahl is 2 or 3, you draw the short line _over top_
of an existing line, which is why you don't see it.
- ajax
___
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: bad karma between mouse and ati6 driver
On Tue, 2015-11-24 at 17:36 +0100, Richard PALO wrote: > > [ 4175.678] (II) RADEON(1): Setting screen physical size to 270 x 203 > > I must say that the screen size '270 x 203' is a bit weird... Physical size here meaning "in millimeters", as opposed to logical size in pixels. - ajax ___ 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: Xorg swapping: bug or expected?
On Mon, 2016-01-11 at 23:37 +0100, Francois wrote: > My question is: is this normal? Do we expect Xorg to swap like any other > program, or does Xorg (should) mlock some of the memory it uses to avoid > swapping? Do you think there is anything else to investigate, or is this > just working as designed? Well it's working as written, whether that can be called "designed" is perhaps arguable. The X server doesn't attempt to mlock itself, and it's not even straightforward to figure out how much it would need to lock to remain responsive, even assuming we could agree what "responsive" was supposed to mean. If we wanted only that cursor updates remain smooth that's still scattered across the server core and whichever input driver is in use. If you want window updates to happen promptly suddenly you're talking about potentially every pixmap held by every application... (and also the compositor, or else every application, since repaints will likely involve IPC). That's not to say mlock couldn't help, but once you get into paging like this, if X's pageins get scheduled behind other disk i/o we've lost and there's nothing X can really do about that. We're ultimately at the mercy of the kernel's block scheduler in any case. That said, if dd is consuming so much memory that it's pushing X out of the working set, I would tend to consider that a flaw in dd (or the user's invocation of it) first. After all dd's working set size is effectively bounded: there will be some optimal buffer size which gets within epsilon of peak read throughput, and for all but the most exotic hardware that's not going to be in the gigabyte range. - ajax ___ 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: IGLX going away? Panic!
On Thu, 2016-05-26 at 16:34 +, Cook, Rich wrote: > Hello, > I recently heard on the Apple x11-users mailing list that remote OpenGL > rendering (IGLX) is being phased out of XOrg and not being replaced. Is > this really the case or am I misunderstanding? You have heard incorrectly. It is _disabled_ by default for security reasons, as it's been a repeated source of exploitable bugs, but the feature itself isn't going away. One caveat is there's no easy way to enable it other than the command line, and not all display managers give you a mechanism to pass arbitrary options in (which is reasonable enough). I've added an xorg.conf option to enable IGLX in master, and I'll be backporting that to the various stable branches as well. - ajax ___ 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
[ANNOUNCE] xorg-server 1.18.1
First release in the 1.18 stable branch. Major themes are bugfixes in glamor, the modesetting driver, and the Present extension. Xwayland users may want to apply the following pair of patches in addition to this release: https://patchwork.freedesktop.org/patch/72945/raw/ https://patchwork.freedesktop.org/patch/72951/raw/ which combined fix an input issue when hotplugging monitors. Both are likely to be included in a future release unless testing discovers further problems. Adam Jackson (11): xnest: Fix needless build dependency on xcb-util-keysyms x86emu: Squash a warning dmx: Silence lex/yacc-related config parser warnings dmx: Silence unused variable warning in dmxcompat dmx: Run 'doxygen -u' to upgrade the doxygen config file glxproxy: Silence set-but-unused-variable warnings glxproxy: Silence shadowed-variable warnings os: Failure to remove a non-existent log file is not an error glx: Fix GLX_EXT_create_context_es2_profile support modesetting: Require sufficiently new libdrm xserver 1.18.1 Alan Coopersmith (2): modesetting should not reference gbm when it's not defined Use unique logfile names when starting server with -displayfd Arkadiusz Miśkiewicz (1): Xorg.wrap: activate libdrm based detection for KMS drivers Bob Ham (1): xserver: Fix configure.ac check for libsystemd/-daemon Chris Wilson (3): present: Requery pending flips with the right sync_flip mode present: When cancelling a pending synchronous flip, requeue it present: Do not replace Pixmaps on redirected Window on unflip Dave Airlie (5): modesetting: drop platform_dev pointer. modesetting: create entities for pci and old probe. (v2) glamor: fallback if font is too large for FBO size. glamor: store old fonts in double width textures. glamor: don't do copy if we have 0 boxes to copy. Egbert Eich (1): kdrive/UnregisterFd: Fix off by one Eric Anholt (8): glamor: Avoid GL errors from mapping with size == 0. glamor: Handle GL_OUT_OF_MEMORY when allocating texture images. glamor: Fix crashes when the glyph atlas allocation fails. glamor: Fix rendering when core font texture allocation fails. glamor: Fix assert failures when fallback picture upload alloc fails. glamor: Fix segfault in fallback picture uploading. glamor: No need to glFlush before destroying a pixmap. glamor: Fix copy-like Render operations between 15 and 16 depth. Jonas Ådahl (1): xwayland: Always update the wl_pointer cursor on pointer focus Julian Pidancet (1): x86emu: Correctly handle 0x66 prefix for some instructions Laércio de Sousa (1): systemd-logind.c: don't parse VT settings for non-seat0 X servers Marek Chalupa (2): xwayland: fix memory leaks on error paths in xwl_realize_window xwayland: check if creating xwl_output succeeded Michael Stapelberg (1): Also dump passive grabs on XF86LogGrabInfo Michel Dänzer (3): prime: Damage full destination rectangle when we start dirty tracking glamor: Disable debugging messages other than GL API errors present: Handle wraparound when comparing MSC values Olivier Fourdan (2): xwayland: Do not set root clip when rootless xwayland: Update screen size on output removal Peter Hutterer (1): xfree86: fix minor memory leak Siim Põder (1): vfb: add randr support (v2) Thomas Klausner (2): Fix uninitialized variable warnings reported by clang Fix build when XSERVER_PLATFORM_BUS is not defined. Timo Aaltonen (1): dri2: Sync i915_pci_ids.h and i965_pci_ids.h from mesa git tag: xorg-server-1.18.1 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.1.tar.bz2 MD5: 1b9e85420c3790dd487addd50313f4da xorg-server-1.18.1.tar.bz2 SHA1: 968fe85773a41296199f8733c7235c8623d7c460 xorg-server-1.18.1.tar.bz2 SHA256: 85ec56dbeb89a951295cdf4f39bf38e515f900d35e06d4a8081b114d1520789d xorg-server-1.18.1.tar.bz2 PGP: http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.1.tar.bz2.sig http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.1.tar.gz MD5: 1e90a30e28f6c9f9b29fb6f42233e2cf xorg-server-1.18.1.tar.gz SHA1: 73009ea90952bcbc790a76020e4c32beff6c9bad xorg-server-1.18.1.tar.gz SHA256: 4de4f05c94441ba9f0279ef3e6cc0d399afc2855d961d1aef2c25a9d10271cf9 xorg-server-1.18.1.tar.gz PGP: http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.1.tar.gz.sig - ajax ___ 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: Problem with X starting when certain USB configurations exist
On Tue, 2016-02-23 at 13:12 -0800, russell.poffenber...@xcerra.com wrote: > What happens is that the X server will not start. The relevant lines from the > X log appears to be.. > > [ 561.239] (II) Loading /usr/lib64/xorg/modules/libint10.so > [ 561.240] (II) Module int10: vendor="X.Org Foundation" > [ 561.240] compiled for 1.15.0, module version = 1.0.0 > [ 561.240] ABI class: X.Org Video Driver, version 15.0 > [ 561.240] (II) VESA(0): initializing int10 > [ 561.240] (EE) VESA(0): V_BIOS address 0x367f0 out of range That's probably a firmware bug. The vesa driver operates by executing the video BIOS code in a real- mode emulator. It expects this code to be located between addresses 0xc and 0xf (ie, where the BIOS lives in the low 1M of RAM in the classic DOS model). To verify this expectation, it examines the software interrupt vector table and checks that it will jump to an address in that range, since int 0x10 and 0x42 are the DOS VBIOS service vectors. For some reason, when you plug in a USB device, the firmware is patching those vectors to point to an address lower than 0xc. (If I had to guess, it's paging in some code to handle USB hubs so it can handle keyboards behind those hubs, and needs to move some video code out of the way to make room; why it bothers to do this after the OS loads, I couldn't imagine, but there may be a BIOS configuration option to make it stop doing that.) Since the vesa driver doesn't have code to map the memory there, it knows that can't work, and refuses to try. I'm reasonably sure CentOS 6 supports booting in UEFI mode, so if you boot in UEFI mode instead of BIOS, you should get efifb for the kernel video device and fbdev for the X driver, which won't have this problem. The problem you will have instead is that efifb can't resize the display, so if the video mode set up by the firmware at boot is wrong there will be no fixing it. But booting in UEFI mode is probably good advice on modern Intel systems in any case, the BIOS path routinely has issues and seems to get much less QA than UEFI. Alternatively, you can wait to see if CentOS 6.8 has native 2D support for Skylake. - ajax ___ 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: Problem with X starting when certain USB configurations exist
On Tue, 2016-03-08 at 16:10 -0800, russell.poffenber...@xcerra.com wrote: > So could there be a bug, or a newer (read fixed) int10 driver in the > Centos 7 version that can be ported to Centos 6.7? Where can I find > the package or code for this driver that I may be able to compile for > Centos 6.7? Interesting. CentOS 7 might behave differently, but it's very unlikely to be the X server or X vesa driver causing that difference; the X code supporting vesa is basically identical between 6.7 and 7.1. It's more likely to be a difference in the boot loader (grub-0.97 vs. grub2) or in the kernel. - ajax ___ 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 to call XDamageSubtract ()
On Tue, 2016-03-08 at 23:56 +, adlo wrote: > I am writing a window switcher application using GTK that shows live > previews of windows. > > Should I call XDamageSubtract () before or after I update the image > widget in response to a damage event? Before, but in another sense, neither. X requests are processed as an arbitrary shuffle of in-order atomic requests from clients. If you subtract before updating, the other client might update the window again in between, which will generate more damage and you'll do excess work, but at least the preview will look right. If you subtract after updating, the client may have updated the window in between, which (if you're using a damage mode other than RawRectangles, which you have to be in order for Subtract to mean anything) might not get reported, and your preview image will be out of sync. Better is to do XGrabServer/XUngrabServer around the two operations, which will prevent any other client from updating in between, in which case the order doesn't matter. You should attempt to minimize the amount of work you do while the server is grabbed (eg just do the ShmGetImage/CopyArea and DamageSubtract, don't do any other requests that would generate a reply) and you should minimize the number of grabs you do (you'll get events far faster than the 60fps your display is probably running at so you should throttle your own framerate) in order to keep the server responsive to other clients. - ajax ___ 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: Major/Minor Opcodes of failed requests
On Wed, 2016-03-30 at 10:03 -0600, Lloyd Brown wrote: > Can anyone help me understand where the error messages, especially the > major and minor opcodes, come from in an error like this one? Are these > defined by Xorg, by the driver (Nvidia, in this case), or somewhere else > entirely? The major opcode is split in two ranges. Major opcodes from 0 to 127 are reserved for requests in the core protocol. Major opcodes from 128 to 255 are assigned dynamically to each extension as it is registered; the minor opcode then determines which extension request it is. > > X Error of failed request: BadAlloc (insufficient resources for > > operation) > > Major opcode of failed request: 135 (GLX) Xlib is polite enough to map the major opcode to the extension here. You can also see the assignments for a particular server by running xdpyinfo -queryExtensions. > > Minor opcode of failed request: 34 () GLX request 34 is X_GLXCreateContextAtrribsARB. The easiest way to look this up in general is to grep for the request number in the appropriate extension header file, usually in /usr/include/X11/extensions, but for GLX it's in /usr/include/GL. The question, then, is why you'd be getting BadAlloc back from glXCreateContextAttribsARB(). - ajax ___ 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
[ANNOUNCE] xorg-server 1.18.3
A few fixes relative to 1.18.2, including one fairly important performance fix to the Present extension. Thanks to all for fixes and testing. Adam Jackson (2): vfb: Re-add LD_EXPORT_SYMBOLS_FLAG to LDFLAGS xserver 1.18.3 Chris Wilson (1): Xext/vidmode: Reduce verbosity of GetModeLine debug messages Dave Airlie (1): glamor: swizzle RED to 0 for alpha textures Michel Dänzer (2): present: Only requeue for next MSC after flip failure xfree86/modes: Make sure the HW cursor is hidden when it should be Olivier Fourdan (2): xwayland: do not include frequency in mode name xwayland: Pretend we support viewport in vidmode Sonny Jiang (1): DRI2: add Polaris PCI IDs git tag: xorg-server-1.18.3 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.bz2 MD5: 043d720bf2472a65bb8f0daa97f83dfa xorg-server-1.18.3.tar.bz2 SHA1: b3d8818bb3e1deeeb8f02d741c1223a72182e63c xorg-server-1.18.3.tar.bz2 SHA256: ea739c22517cdbe2b5f7c0a5fd05fe8a10ac0629003e71c0c7862f4bb60142cd xorg-server-1.18.3.tar.bz2 PGP: http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.bz2.sig http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.gz MD5: f077e27a91bc9c37e3b78958454c9dd2 xorg-server-1.18.3.tar.gz SHA1: 21fdf20305d01bf0123ed0a4f1a30d079134 xorg-server-1.18.3.tar.gz SHA256: 9b872f946b912f11a0ffc911d936764fce604ee4ac65ee1f131b78b3e89ede26 xorg-server-1.18.3.tar.gz PGP: http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.18.3.tar.gz.sig - ajax 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: Strange results from xdpyinfo
On Mon, 2016-04-25 at 16:47 +0200, Thomas Lübking wrote: > On Sat, Apr 23, 2016 at 08:59:09PM +0300, Ilya Anfimov wrote: > > Such a pity. > > Oh, don't be such a cunt ;-P Let's have less of this, thanks. - ajax ___ 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: inexplicable fallback mode used when preferred mode 2560x1080 not supported by connection
On Sun, 2017-02-12 at 05:10 -0500, Felix Miata wrote: > http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log-big31-ostw-d2913wm.txt is > Xorg.0.log plus output from inxi -c0 -G, hwinfo --gfxcard and xrandr from a > GT210[1] on host big31 booted to openSUSE Tumbleweed and modesetting driver, > which falls to 1400x1050 using an HDMI cable. Using instead nouveau, fall is > to > 1152x864, same as same PC booted to openSUSE 42.1 using HDMI and modesetting > driver, and same PC booted to Fedora 25 using HDMI and nouveau driver. Can you add Option "ModeDebug" "true" to your Device section in xorg.conf and give the log from that? - ajax ___ 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
[ANNOUNCE] libXfont 1.5.2
Maintenance branch release, primarily for bdftopcf's benefit as it's the only thing that really needs the Xfont1 API. (xfs uses it too, I believe, but could be ported to Xfont2). If someone wanted to step up and merge Xfont1 into bdtopcf directly, that'd be great. Adam Jackson (1): libXfont 1.5.2 Alan Coopersmith (1): doc: add a couple olinks to fsproto & xfs-design docs Benjamin Tissoires (1): bdfReadCharacters: Allow negative DWIDTH values Jeremy Huddleston Sequoia (6): stubs: Add missing externs for declarations in the NO_WEAK_SYMBOLS && PIC stubs resolution Use NO_WEAK_SYMBOLS instead of -flat_namespace FreeType: Correct an allocation size bitmap: Bail out on invalid input to FontFileMakeDir instead of calling calloc for 0 bytes fserve: Silence a -Wformat warning fserve: Fix a buffer read overrun in _fs_client_access Keith Packard (1): Fix warnings Thomas Klausner (1): Fix is*() usage. git tag: libXfont-1.5.2 http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.2.tar.bz2 MD5: 254ee42bd178d18ebc7a73aacfde7f79 libXfont-1.5.2.tar.bz2 SHA1: a9470774f271622c1b425826d1c8836ed96e4a96 libXfont-1.5.2.tar.bz2 SHA256: 02945ea68da447102f3e6c2b896c1d2061fd115de99404facc2aca3ad7010d71 libXfont-1.5.2.tar.bz2 PGP: http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.2.tar.bz2.sig http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.2.tar.gz MD5: e8c616db0e59df4614980915e79bb05e libXfont-1.5.2.tar.gz SHA1: 71fd30da5d2dd7a93c363262f66c7a4217a120a8 libXfont-1.5.2.tar.gz SHA256: a7350c75171d03d06ae0d623e42240356d6d3e1ac7dfe606639bf20f0d653c93 libXfont-1.5.2.tar.gz PGP: http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.2.tar.gz.sig - ajax 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: damage.c wrapping bug?
On Wed, 2016-09-14 at 14:01 -0400, Stirling Westrup wrote: > I'm currently reading through the source for the damage extension in > damage.c and I noticed that the list of functions that get wrapped > when a screen gets damage support is not the same as the list of > functions that get unwrapped when the screen is closed. That is > DamageSetup() wraps these functions: > > DestroyPixmap -> damageDestroyPixmap > CreateGC -> damageCreateGC > DestroyWindow -> damageDestroyWindow > SetWindowPixmap -> damageSetWindowPixmap > CopyWindow -> damageCopyWindow > CloseScreen -> damageCloseScreen > > but inside damageCloseScreen, the list of functions that get restored > are: > > DestroyPixmap > CreateGC > CopyWindow > CloseScreen > > and neither SetWindowPixmap nor DestroyWindow are ever unwrapped. Is > this an issue, or is there some reason to believe this isn't a > problem? It's a bug, though it's probably harmless. On the next generation fbScreenInit (or whatever the bottom dispatch layer happens to be) is going to reinitialize those slots in the ScreenRec, and since it's the bottom layer it's not going to wrap them but just install them. - ajax ___ 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: hay guys why isn't XOpenDisplay()'s argument const char?
On Wed, 2016-10-05 at 11:48 +0900, Ashe Goulding wrote: > Is it safe to regard it as const char? Yes. libX11 predates the wide availability of C89, so it tends not to include things like 'const' in function signatures. - ajax ___ 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: display/GFX issue with Ubuntu 16.04 not seen in 14.04
On Tue, 2016-08-23 at 06:53 -0400, Jim Abernathy wrote: > Can someone let me know where I can ask questions regarding problems > with X?? I thought this forum would be the place? Most issues of this sort are more in the video driver than in X itself. intel-...@lists.freedesktop.org is probably a more likely place to ask, since you're using an Intel GPU. - ajax ___ 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 & xf86OpenConsole : setpg Operation not permitted & FBIOPUTCMAP: Invalid argument
On Tue, 2016-12-06 at 09:22 +, Micka wrote: > Hi, > > I'm having trouble with the configuration of the Xorg ! Can someone > give me some advise ? You are? There's nothing fatal happening in this log, can you be more explicit about what's going wrong? In particular: > [327741.772] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument This just says that drm's fbdev emulation doesn't have colormap support wired up, which is harmless. - ajax ___ 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: How to avoid this Xvfb error: ES2 Prism: Error - GLX extension is not supported
On Mon, 2016-12-12 at 12:13 -0500, Long Vu wrote: > Would it be this xvfb-run option ? > > -s ARGS --server-args=ARGSarguments (other than server number and > "-nolisten tcp") to pass to the Xvfb > server > (default: "-screen 0 640x480x8") > > I am not familiar with X server options, what server args I would need > to get rid of this "ES2 Prism: Error - GLX extension is not supported" > error? Yes, I think it would be: xvfb-run -s "-screen 0 640x480x24" # ... whatever else you use - ajax ___ 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: How to avoid this Xvfb error: ES2 Prism: Error - GLX extension is not supported
On Fri, 2016-12-09 at 14:09 -0500, Long Vu wrote: > Hi, > > We use Xvfb to avoid having to run an X server on our build machine. > > We got this error with Xvfb that we do not have when we were running a > real VNC server just to provide X. > > ES2 Prism: Error - GLX extension is not supported > GLX version 1.3 or higher is required > Xlib: extension "RANDR" missing on display ":99". > > Is there something we can do to avoid this error? How are you launching Xvfb? I believe it defaults to 8bpp, but GLX only works at 16 or 32bpp. - ajax ___ 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
[ANNOUNCE] xorg-server 1.19.1
First stable 1.19 release, including a few regression fixes. Thanks to all who contributed! Adam Jackson (3): Revert "damage: Make damageRegionProcessPending take a damage not a drawable" composite: Fix repaint of borders (v2) xserver 1.19.1 Ben Crocker (1): Fix a segfault that occurs if xorg.conf.d is absent: Hans De Goede (1): glamor: Trust eglGetPlatformDisplayEXT if it exists Hans de Goede (2): randr: rrCheckPixmapBounding: Do not substract crtc non 0 x,y from screen size randr: rrCheckPixmapBounding: do not shrink the screen_pixmap Kai-Heng Feng (1): edid: Add quirk for ADA 1024x600 7" display. Keith Packard (1): AttendClient of grab-pervious client must queue to saved_ready_clients [v2] Michal Srb (1): xinerama: Swap the response in RRXineramaWriteMonitor Michel Dänzer (1): present: Only call present_flip_notify if vblank->queued == FALSE Mihail Konev (1): os,dix: Depend custom libs on libs, not objects Olivier Fourdan (2): glamor: restore vfunc handlers on init failure xwayland: Fix use after free of cursors Pekka Paalanen (1): test: fix distributing scripts Peter Hutterer (2): Xi: when creating a new master device, update barries for all clients os: return 0 from check_timers if we touched any of them Qiang Yu (2): xfree86: fix wrong usage of xf86optionListMerge randr: fix xserver crash when xrandr setprovideroutputsource Rhys Kidd (1): test: Fix stray Makefile reference to removed os test Rui Matos (1): xwayland: Don't send KeyRelease events on wl_keyboard::leave git tag: xorg-server-1.19.1 https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.1.tar.bz2 MD5: caa8ee7b2950abbf734347d137529fb6 xorg-server-1.19.1.tar.bz2 SHA1: 13c81e0ebb6ac1359a611d0503805c6dc0315477 xorg-server-1.19.1.tar.bz2 SHA256: 79ae2cf39d3f6c4a91201d8dad549d1d774b3420073c5a70d390040aa965a7fb xorg-server-1.19.1.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.1.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.1.tar.gz MD5: bba0ef0fab6cfaa081a49d4b6de1fef3 xorg-server-1.19.1.tar.gz SHA1: 43609db8a8d9cfed53d5185a38309f2ae6582713 xorg-server-1.19.1.tar.gz SHA256: 24c7419a963f55eeed5951541344cd616196ae97c273e17b32ad7f0c3658bf2b xorg-server-1.19.1.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.1.tar.gz.sig - ajax 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: What does this backtrace mean?
On Wed, 2016-11-30 at 13:01 -0500, Alex Villacís Lasso wrote: > El 28/11/16 a las 19:59, Alex Villacís Lasso escribió: > > I have this computer (Acer Aspire One ZG5 using Fedora 25 32-bits) > > where the backtrace shown below appears every single time the > > machine boots. What does it mean? Should I be worried about it? > > Last seen on kernel version 4.8.8. > > > > Is this the right list to ask this question? Maybe. intel-...@lists.freedesktop.org might be more appropriate since this is a kernel driver bug. > > [4.884815] WARN_ON(!connector->state->crtc) What this is saying is the driver had some expectations about the state the hardware would be in when efifb handed the device off, and those expectations were violated. If there's no functional problem you can safely ignore it, but it's a kernel driver bug either way. - ajax ___ 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] xf86-video-ati 7.9.0
On Thu, 2017-03-16 at 10:59 +0100, poma wrote: > There are two applicable patches within Fedora: > https://src.fedoraproject.org/cgit/rpms/xorg-x11-drv-ati.git/commit/fix-dri-removal.patch?id=d5f48e7d5b6c An artifact of Fedora trying to not build DRI1. It's a fix in the wrong place, xserver should define the appropriate symbols if any DRI is built. > https://src.fedoraproject.org/cgit/rpms/xorg-x11-drv-ati.git/commit/radeon-6.12.2-lvds-default-modes.patch?id=9495e5b874d8 Mostly a hack for LCDs that only claim one supported resolution and desktop environments too chicken to let you set arbitrary modes from the display control panel. Again, not really thrilled with the implementation of it, might be better solved in another place. > Are these patches required, if so, care to explain? "Required", no. Nice to have, arguably. - ajax ___ 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
[ANNOUNCE] xorg-server 1.19.3
A couple more minor fixes, most notably a revert of a page-flipping change that regressed some drivers. Adam Jackson (2): Revert "present: Allow flipping with PRIME slave outputs" xserver 1.19.3 Chris Wilson (2): Revert "prime: Sync shared pixmap from root window instead of screen pixmap" os: Fix iteration over busfaults Dr.-Ing. Dieter Jurzitza (1): glamor: Fix missing declaration in dash vertex shader Olivier Fourdan (2): xwayland: clear cursor frame callback xwayland: Monitor client states to destroy callbacks Qiang Yu (1): present: disable page flip only when a slave crtc is active Tobias Stoeckmann (1): render: Fix out of boundary heap access git tag: xorg-server-1.19.3 https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.3.tar.bz2 MD5: 015d2fc4b9f2bfe7a626edb63a62c65e xorg-server-1.19.3.tar.bz2 SHA1: 77f580ffa22a8bbcc3536e74e19114e446417a9c xorg-server-1.19.3.tar.bz2 SHA256: 677a8166e03474719238dfe396ce673c4234735464d6dadf2959b600d20e5a98 xorg-server-1.19.3.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.3.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.3.tar.gz MD5: a7a51420874af84d90720b60de7936be xorg-server-1.19.3.tar.gz SHA1: 30009ac9da414389afc30b5d61576a793778b639 xorg-server-1.19.3.tar.gz SHA256: 8f93b98f1ac9fbd87515bfe329a069b48bbec98e5329584ab5fbf759a0953b8d xorg-server-1.19.3.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.3.tar.gz.sig - ajax ___ 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] xorg-server 1.19.2
On Thu, 2017-03-02 at 18:13 -0500, Adam Jackson wrote: > A collection of stability fixes here across glamor, Xwayland, input, > and Prime support. Also a security fix for CVE-2017-2624, a timing > attack which can brute-force MIT-MAGIC-COOKIE authentication. Everybody > is encouraged to upgrade. Thanks to all who contributed fixes! As several people have noticed, this tarballs is missing some of the standard buildsystem bits, such that you need to run autoreconf before ./configure. This is partly my fault for driving the release script incorrectly, and mostly autotools' fault for being sheer garbage. (Seriously, dear gnu project, please sunset autotools. It is a net loss to humanity at this point.) Once I beat the release tools into submission I'll upload 1.19.3 with otherwise the same content. Sorry for the mess. - ajax ___ 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: Dropped kdrive == fbdev regression
On Fri, 2017-03-10 at 12:52 +, Steven Newbury wrote:
> Since kdrive, in particular Xfbdev has been dropped, this has left a
> hole in support for MONO (1bpp) framebuffer devices. I've been using
> Xfbdev for a picolcd mono matrix device for a few years.
>
> The Xorg fbdev driver only supports a minimum of 8bpp framebuffer
> formats which wasn't a problem given the existance of Xfbdev, but now
> leaves a whole class of hardware unsupportable.
Looks like this is just an oversight in the fbdev driver. Care to try a
patch?
diff --git a/src/fbdev.c b/src/fbdev.c
index af1587f..0da63fb 100644
--- a/src/fbdev.c
+++ b/src/fbdev.c
@@ -623,6 +623,7 @@ FBDevPreInit(ScrnInfoPtr pScrn, int flags)
case FBDEVHW_PACKED_PIXELS:
switch (pScrn->bitsPerPixel)
{
+ case 1:
case 8:
case 16:
case 24:
- ajax
___
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: help with Xorg (Adam Jackson)
On Mon, 2017-07-31 at 12:15 -0500, Perez Rodriguez, Humberto I wrote: > Hi Adam : > > there is the full log This log appears to show a successful startup. You say you only see a blank screen, but a black background with no cursor is in fact the default. If you're simply trying to test whether X works, the '-retro' command line option will paint the old root weave and X cursor. But otherwise X doesn't draw anything on its own, and you will need to actually run some X clients against your X server if you want to see anything. - ajax ___ 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: help with Xorg
On Thu, 2017-07-27 at 21:59 -0500, Perez Rodriguez, Humberto I wrote: > (04:54 PM) [gfx@gfx-desktop] [xorg]$ : cat Xorg.0.log | grep "(WW)" > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [62.765] (WW) The directory "/usr/share/fonts/misc/" does not exist. > [62.765] (WW) The directory "/usr/share/fonts/TTF/" does not exist. > [62.765] (WW) The directory "/usr/share/fonts/OTF/" does not exist. > [62.766] (WW) The directory "/usr/share/fonts/Type1/" does not exist. > [62.766] (WW) The directory "/usr/share/fonts/100dpi/" does not exist. > [62.766] (WW) The directory "/usr/share/fonts/75dpi/" does not exist. > [62.944] (WW) Falling back to old probe method for modesetting > [62.944] (WW) Falling back to old probe method for fbdev > [62.946] (WW) Falling back to old probe method for vesa > [62.946] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card > support > [ 292.184] (WW) Option "xkb_variant" requires a string value > [ 292.184] (WW) Option "xkb_options" requires a string value > > > i think that the issue is in the line "VGA arbiter: cannot open kernel > arbiter, no multi-card support" but i am not sure about that It almost certainly is not the issue. Please just provide the full X log instead of grepping randomly. - ajax ___ 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: Is this issue related with the bug 20048 , 17923 or 71338
On Fri, 2017-08-04 at 05:55 +, Subrata Dasgupta wrote: > Hi Ajax, > Why every time XErrorEvent.serial = 2422603788. Does not it mean > application is facing problem only after a certain number of requests > has been made?? It means the error structure points to a place in memory that consistently contains that value, yes. But an XErrorEvent is only sent for protocol errors, not disconnections, so I'm pretty sure that's just a coincidence. To wit: > Can you please provide where from I get information about the > error_code, request_code and minor_codes of XErrorEvent structure > because I want to understand the meaning of the following codes. > > XErrorEvent.error_code = 84 > XErrorEvent.request_code = 131 > XErrorEvent.minor_code = 4 You can discover the mappings for these from 'xdpyinfo -queryExtensions', which will list the error and event bases and extension opcode for each extension. Extension codes are assigned dynamically so this will depend on the specific server you're talking to. On my machine: % xdpyinfo -queryExtensions | grep 131 XInputExtension (opcode: 131, base event: 66, base error: 129) The "error code" is also used for event codes, and xinput does indeed have a lot of events, but that reinforces my point. Extension events are between 64 and 127, and extension errors are between 128 and 255. This event says error_code = 84, which means (assuming you trust that the XErrorEvent struct was pointing to valid data) that what you're looking at is _not a protocol error_. > For a huge X application this should not be a coincidence. Most > importantly this behavior seems to be related with the bug 71338. > When I checked my libxcb.so and libX11.so it seems 4 functions > proposed for the fix for 71338(xcb_send_request64, > xcb_discard_reply64, xcb_wait_for_reply64, xcb_poll_for_reply64) are > present within the libxcb.so but libX11 do not use the function > xcb_send_request64 or xcb_discard_reply64 within it. Why this is so > ?? Those are the functions responsible for processing data from the server, so of course they will be in the backtrace for any fatal connection error. - ajax ___ 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: How to convert ZPixMap to BGRA reliably?
On Tue, 2017-08-22 at 11:39 +0530, Sai Prasanna wrote: > I thought Zpixmap mapped directly to BGRA. But my assumption didn't > turn out to be correct in some older X versions. > > I am using xcb_get_image and xcb_shm_get_image to grab screen pixels. > I used Zpixmap option for image format. In new-ish Xorg versions it > works perfectly. > > But in some machines with older Xorg (1.15 and below) , I get > discolored, overlapped data, and it is less than 4 * width * height > bytes. If I try to read with bytes per pixel as 4 , overflow occurs. Which machines are these, specifically? In particular, when you run xdpyinfo, you should see a line for the depth-24 pixmap format, like this: depth 24, bits_per_pixel 32, scanline_pad 32 Some older servers may instead have bits_per_pixel == 24, in which case the data is missing the "A" channel, which would explain the buffer overrun you're seeing (which I bet happens at 3 * width * height). Newer servers and drivers attempt to hide 24bpp formats from clients for exactly this reason. - ajax ___ 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: Xvfb concerns and dummy driver issues
On Fri, 2017-04-28 at 14:24 -0400, David Jackson wrote: > Is the plan to keep Xvfb as-is (KDrive?) As-is, yes. Strictly speaking, Xvfb is not a kdrive server, in the same sense that Xorg is not a kdrive server. There was a very similar kdrive server named Xfake, and that was indeed deleted. > Any ideas about why the dummy driver was not working (killing the > headless dummy X server brings down any X server running on hardware, > like the dummy X server somehow gets entangled with other X servers > on the system), By default, the Xorg server will remember which virtual terminal it was launched from (if any), and will attempt to switch back to it when it exits (or regenerates). So if you start both the dummy and hardware server from the console, terminating either one will switch back to the console, which may look like you're "bringing down" the other one. You can suppress this by launching the dummy server with '-novtswitch' on the command line. > and problems playing video? I'm not sure this is specific enough to guess at. - ajax ___ 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 crashing in pci_device_vgaarb_set_target
On Mon, 2017-10-09 at 13:07 +0200, Peter Kasza wrote: > Hi all, > > I'm getting itermittent crashes on a vfio enabled machine. I'm not > able to recreate it on purpose, but it seems to be occurring when > virtualbox VMs and Firefox are running. > > From the backtrace I suspect that some bogus parameter is passed to > the snprintf call, but other than that I'm not sure. > > The crash occurs in libpciaccess - pci_device_vgaarb_set_target. I > have the latest release installed (0.13.5). > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x7f17082667a3 in __GI__IO_default_xsputn () from /usr/lib/libc.so.6 > [Current thread is 1 (Thread 0x7f170aa11940 (LWP 491))] > (gdb) bt > #0 0x7f17082667a3 in __GI__IO_default_xsputn () at /usr/lib/libc.so.6 > #1 0x7f1708259b2d in __GI__IO_padn () at /usr/lib/libc.so.6 > #2 0x7f1708239938 in vfprintf () at /usr/lib/libc.so.6 > #3 0x7f17082efcbb in __vsnprintf_chk () at /usr/lib/libc.so.6 > #4 0x7f17082efbe5 in __snprintf_chk () at /usr/lib/libc.so.6 > #5 0x7f1709a966b8 in pci_device_vgaarb_set_target () at > /usr/lib/libpciaccess.so.0 > #6 0x5616427d1fc8 in () Any chance you can (install debuginfo and) see the rest of this call trace? I suspect the value of 'dev' being passed into pci_device_vgaarb_set_target is just bogus, but without the call trace up through Xorg it's hard to see how that could happen. - ajax ___ 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
[ANNOUNCE] xorg-server 1.19.4
A collection of stability fixes from the development branch, including two minor CVEs. Thanks to all who sent in patches! Aaron Plattner (1): randr: Use RRTransformEqual in RRCrtcPendingTransform Adam Jackson (11): parser: Fix crash when xf86nameCompare(s1 = x, s2 = NULL) xinerama: Implement graphics exposures for window->pixmap copies (v4) ephyr: Don't clobber bitsPerPixel when using glamor xephyr: Check for host XVideo support before trying to use it modesetting: Validate the atom for enum properties wayland: Sync drm.xml with Mesa os: Fix warning in LockServer xfree86: Silence a new glibc warning dmx: Silence an unused-result warning dmx: Remove some not-very-interesting debug prints xserver 1.19.4 Carlos Garnacho (5): xwayland: Allow pointer warp on root/None window xwayland: "Accept" confineTo on InputOnly windows xwayland: Update root window size when desktop size changes xwayland: Lock the pointer if it is confined and has no cursor Xi: Use WarpPointerProc hook on XI pointer warping implementation Daniel Stone (1): modesetting: Set correct DRM event context version Dawid Kurek (1): modesetting: Blacklist EVDI devices from PRIME sync Eric Anholt (1): glamor: Fix dashed line rendering. Jason Gerecke (1): xfree86: Fix interpretation of xf86WaitForInput timeout Jon TURNEY (1): Move statically linked xorgxkb files from dixmods to a separate directory Keith Packard (6): os: un-duplicate code to close client on write failure os: Mark client as ready to read when closing due to write failure [100863] dix: Remove clients from input and output ready queues after closing modesetting: Skip no-longer-present connectors when resetting BAD links xkb: Handle xkb formated string output safely (CVE-2017-13723) xf86-video-modesetting: Add ms_queue_vblank helper [v3] Kenneth Graunke (1): dri2: Sync i965_pci_ids.h from Mesa. Louis-Francis Ratté-Boulianne (1): present: Check the whole exec queue on event Lyude (1): xwayland: Don't load extension list more than once Martin Peres (1): modesetting: re-set the crtc's mode when link-status goes BAD Michal Srb (7): Xi: Zero target buffer in SProcXSendExtensionEvent. dix: Disallow GenericEvent in SendEvent request. Xi: Verify all events in ProcXSendExtensionEvent. Xi: Do not try to swap GenericEvent. Xi: Test exact size of XIBarrierReleasePointer Xext/shm: Validate shmseg resource id (CVE-2017-13721) xkb: Escape non-printable characters correctly. Michel Dänzer (5): xfree86/modes: Make colormap/gamma glue code work with RandR disabled os: Handle SIGABRT glamor: Store the actual EGL/GLX context pointer in lastGLContext glamor: Fix temporary pixmap coordinate offsets xfree86/modes: Use RRTransformEqual in xf86RandR12CrtcSet Nick Sarnie (1): suid: Include sysmacros.h to fix build after glibc-2.25 Olivier Fourdan (9): glamor: Check for NULL pixmap in glamor_get_pixmap_texture() Xephyr: Check screen resources creation success glamor: glamor_set_destination_drawable() can fail glamor: Check glamor_set_destination_drawable() return value glamor: avoid a crash if texture allocation failed glamor: an FBO is not needed for Xv pixmaps xwayland: Fix a segfault with pointer locking glamor: handle NULL source picture glamor: Avoid overflow between box32 and box16 box Peter Hutterer (2): test: fix compiler warning xfree86: up the path name size to 512 in xf86MatchDriverFromFiles Rodrigo Vivi (1): dri2: Sync i965_pci_ids.h from Mesa. Tobias Stoeckmann (2): record: Fix OOB access in ProcRecordUnregisterClients dmx: Fix null pointer dereference https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.4.tar.bz2 MD5: 28cb6d773bfcdfd43500dd64527d2ab0 xorg-server-1.19.4.tar.bz2 SHA1: 7a47d5f927ea69681e279c6e5f5e8ff3a21c7152 xorg-server-1.19.4.tar.bz2 SHA256: aa758acea91deaf1f95069ddc5ea3818e13675fb14fef40ad1b3d0b2bf03c9a8 xorg-server-1.19.4.tar.bz2 SHA512: ff80934e42a7dd2d437e947fe02c74c3b25bdbb3002b7005191d52272d5eae8cb3a83377fa32f4011be88405830e796f6bd3b914bd7fc163ea8ece76226b xorg-server-1.19.4.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.4.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.4.tar.gz MD5: 8e3bbbd95da197dd50fdba4d2bf0a947 xorg-server-1.19.4.tar.gz SHA1: 06d281e2bf5205d40ff3cf6e31a92556e5ac4222 xorg-server-1.19.4.tar.gz SHA256: a1c87baa073faa3b7eb11610dd2c89a25586c71f861d32265fc26e11d12fafed xorg-server-1.19.4.tar.gz SHA512: c589ad455ae287a22d110f9d067d61b000a4d30564df912c4f29e0d57c955c32f9b56bfd85a8df4d01584c37dd64d9747ec48ec0e121679f604bb988b481f7eb xorg-server-1.19.4.tar.gz PGP: https://xorg.fr
[ANNOUNCE] libXRes 1.2.0
Version 1.2 of the X-Resource extension (added in xserver 1.13) added some new requests allowing inspection of every resource for a client, the bytes used per resource, and the PIDs of local clients. Unfortunately the client library never saw a corresponding release, so let's fix that. Adam Jackson (2): configure: Remove AM_MAINTAINER_MODE libXRes 1.2.0 Alan Coopersmith (6): Bump version to 1.1.99.0 to reflect addition of 1.2 API Replace deprecated Automake INCLUDES variable with AM_CPPFLAGS Use _XEatDataWords to avoid overflow of rep.length shifting integer overflow in XResQueryClients() [CVE-2013-1988 1/2] integer overflow in XResQueryClientResources() [CVE-2013-1988 2/2] Remove fallback for _XEatDataWords, require libX11 1.6 for it Colin Walters (1): autogen.sh: Implement GNOME Build API Emil Velikov (1): autogen.sh: use quoted string variables Erkki Seppälä (2): Implemented first part of XResource extension v1.2: XResQueryClientIds Implemented second part of XResource extension v1.2: XResQueryResourceBytes Julien Cristau (1): Compute number of bytes correctly in XResQueryClientPixmapBytes Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish git tag: libXres-1.2.0 https://xorg.freedesktop.org/archive/individual/lib/libXres-1.2.0.tar.bz2 MD5: 5d6d443d1abc8e1f6fc1c57fb27729bb libXres-1.2.0.tar.bz2 SHA1: b6996ab05460a3b7311f02da23ddf117a5442fd9 libXres-1.2.0.tar.bz2 SHA256: ff75c1643488e64a7cfbced27486f0f944801319c84c18d3bd3da6bf28c812d4 libXres-1.2.0.tar.bz2 SHA512: 8eb5a36b1f030eb4e27e676cc4befcc073da66a7bce2b39089314e1facb629d13b087bb53ca2c95fe5291857da7ff9f80c6ab28fb3e245eeb9e0344937900172 libXres-1.2.0.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/lib/libXres-1.2.0.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/lib/libXres-1.2.0.tar.gz MD5: 8c853e0e0f52e0bdc2bdbb72ac0f3df3 libXres-1.2.0.tar.gz SHA1: 58582036677e033d35ec831e4523fa64b5bd2d79 libXres-1.2.0.tar.gz SHA256: 5b62feee09f276d74054787df030fceb41034de84174abec6d81c591145e043a libXres-1.2.0.tar.gz SHA512: 305615ccd903a9ada6e6ae3a8b200471636e05823ed33f3a704dd9c26ba2729a0fc7490317cdee35a0bd365ba5b995fc5f4238389107afb898377c0e100d7c1a libXres-1.2.0.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/lib/libXres-1.2.0.tar.gz.sig - ajax 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
[ANNOUNCE] libXfont2 2.0.2
A collection of minor fixes since 2.0.1, including CVEs 2017-13720 and 2017-13722. Adam Jackson (5): configure: Use -fvisibility=hidden if available autogen: Set a default subject prefix for patches freetype: Fix a logic error in computing face name readme: Update for libXfont 2.0 interface change libXfont 2.0.2 Emil Velikov (1): autogen.sh: use quoted string variables Jeremy Huddleston Sequoia (5): FreeType: Correct an allocation size bitmap: Bail out on invalid input to FontFileMakeDir instead of calling calloc for 0 bytes fserve: Silence a -Wformat warning fstrans: Remove unused foo() function fserve: Fix a buffer read overrun in _fs_client_access Keith Packard (1): Revert "Add compiler warning flags". Leave warning fixes. Michal Srb (2): Check for end of string in PatternMatch (CVE-2017-13720) pcfGetProperties: Check string boundaries (CVE-2017-13722) Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish git tag: libXfont2-2.0.2 https://xorg.freedesktop.org/archive/individual/lib/libXfont2-2.0.2.tar.bz2 MD5: d39e6446e46f939486d1a8b856e8b67b libXfont2-2.0.2.tar.bz2 SHA1: d5117914a026b3fd47123cb1c2a22daaae3b63e4 libXfont2-2.0.2.tar.bz2 SHA256: 94088d3b87f7d42c7116d9adaad155859e93330c6e47f5989f2de600b9a6c111 libXfont2-2.0.2.tar.bz2 SHA512: d62b0c3d663a2c668796cca8c6c2a90f83feeae1253b7d946668d33502cd8099c963285b88db4f745efb0d4ff783c118eb3d84cb8e6e1724586e1ef2be23e593 libXfont2-2.0.2.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/lib/libXfont2-2.0.2.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/lib/libXfont2-2.0.2.tar.gz MD5: 325233b04b715a93fa6548004a21c1c9 libXfont2-2.0.2.tar.gz SHA1: 3df365812830d7c19f9c71cffc633b82eaee726d libXfont2-2.0.2.tar.gz SHA256: b82dd7f5c5c4820dfced428da8bfc13a8cd25ce25e8119d337ae0bc6f9507814 libXfont2-2.0.2.tar.gz SHA512: 719ba126aa058eaa0b24a2b475be67391e6740a5cb5e12e3b0150bab82560102e41599d945704dc07e1e854736ebfcf27d97faf042931f9591e7d1c64632 libXfont2-2.0.2.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/lib/libXfont2-2.0.2.tar.gz.sig - ajax 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
[ANNOUNCE] xorg-server 1.19.5
One regression fix since 1.19.4 (mea culpa), and fixes for CVEs 2017- 12176 through 2017-12187. C is a terrible language, please stop writing code in it. Adam Jackson (2): Revert "xf86-video-modesetting: Add ms_queue_vblank helper [v3]" xserver 1.19.5 Michal Srb (1): os: Make sure big requests have sufficient length. Nathan Kidd (7): Unvalidated lengths xfixes: unvalidated lengths (CVE-2017-12183) hw/xfree86: unvalidated lengths Xi: integer overflow and unvalidated length in (S)ProcXIBarrierReleasePointer Xi: fix wrong extra length check in ProcXIChangeHierarchy (CVE-2017-12178) dbe: Unvalidated variable-length request in ProcDbeGetVisualInfo (CVE-2017-12177) Unvalidated extra length in ProcEstablishConnection (CVE-2017-12176) git tag: xorg-server-1.19.5 https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.bz2 MD5: 4ac6feeae6790436ce9de879ca9a3bf8 xorg-server-1.19.5.tar.bz2 SHA1: 307d3405f709f7e41966c850b37deefe7f83eb9b xorg-server-1.19.5.tar.bz2 SHA256: 18fffa8eb93d06d2800d06321fc0df4d357684d8d714315a66d8dfa7df251447 xorg-server-1.19.5.tar.bz2 SHA512: 928dea5850b98cd815004cfa133eca23cfa9521920c934c68a92787f2cae13cca1534eee772a4fb74b8ae8cb92662b5d68b95b834c8aa8ec57cd57cb4e5dd45c xorg-server-1.19.5.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.gz MD5: 97ab05c006718d6d484e4e5fe1aec534 xorg-server-1.19.5.tar.gz SHA1: 842cc1fbc26887698a70c6ad538bb07fa94b0130 xorg-server-1.19.5.tar.gz SHA256: 1818068b6b86387ee0e392cbe28208ff949d253a1611d17bf2908961f3669b1c xorg-server-1.19.5.tar.gz SHA512: 34f10c22bc7e003245c423288c495ef98707d7ba23ff4207d6dfde32e917fd752acc285e65da39805e74cfa275a655b1b0bf07bb5d2bc82a773854a17bc81ded xorg-server-1.19.5.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.5.tar.gz.sig - ajax 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
[ANNOUNCE] xfs 1.2.0
This release ports the X Font Server to libXfont 2.x. Distributions may now drop libXfont 1.x at their convenience. This conversion has been lightly tested but some issues may remain; please report any new issues to xorg-de...@lists.x.org. Adam Jackson (3): xtrans: Simplify an error path when started from inetd xfs: port to libXfont2 xfs 1.2.0 Alan Coopersmith (2): Add const to port variable passed to TRANS(ReopenCOTSServer) Fix memory leaks when not using alloca Emil Velikov (1): autogen.sh: use quoted string variables Matthew Green (1): FD_SETSIZE fixes. Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish Thomas Klausner (2): Ignore .dirstamp files. Include config.h first, and add comment about Xpoll.h. git tag: xfs-1.2.0 https://xorg.freedesktop.org/archive/individual/app/xfs-1.2.0.tar.bz2 MD5: b4d2e644bfb35cae8858d2411501b07e xfs-1.2.0.tar.bz2 SHA1: 00848fcc2915ed8b00e75ac311c4727327324f57 xfs-1.2.0.tar.bz2 SHA256: db2212115783498f8eeaaee1349461d6c4e9d2005e142bacd3a984fe57269860 xfs-1.2.0.tar.bz2 SHA512: 557b08aa07919239ce345d60b288b886640200bb1a59649fc890c3ccaa8559cc6745189614e696ab1b390ec024b393be5493787b7b0d2b3545b342d743c2e0ef xfs-1.2.0.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/app/xfs-1.2.0.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/app/xfs-1.2.0.tar.gz MD5: 659d966e998cf1512a037e0fdde178de xfs-1.2.0.tar.gz SHA1: 7fd38af0e8cd56172e85784b7214be9c70753b35 xfs-1.2.0.tar.gz SHA256: 56ebdc5ff85af332a0c5dc60c9b971551624bbc312bf6af3d13b925600ea367f xfs-1.2.0.tar.gz SHA512: 3db541a8b761416f68c8f9ab99264f04fc0d084248e10755ba83ccab2b41cb9ba2b6885d63071d7de07d1b0ac9ca88f943ab33b25b36efb96dadebeae0d8303e xfs-1.2.0.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/app/xfs-1.2.0.tar.gz.sig - ajax 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: monitor hotplug resolution switch
On Tue, 2017-12-12 at 11:22 +, Johann Obermayr wrote: > Hello, > > i have a x86 machine with i915 graphics. > With connected display (1920x1080) all is ok. > But if I disconnect the monitor, the resolution switch to 320x200. > > How can I disable this ? The X server does not resize anything on its own, only when a client tells it to. Figure out what part of your desktop environment is responsible for screen configuration, and tell it to stop resizing the desktop just because the monitor went away. - ajax ___ 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
[ANNOUNCE] bdftopcf 1.1
This release imports the libXfont 1.x BDF-reading and PCF-writing code, as this program is the only known user of that code and libXfont 1.x is otherwise unmaintained. No functional difference should be apparent, this is just another step towards eliminating the old version of libXfont from the world. Adam Jackson (3): Import libXfont's BDF-to-PCF code Import more libXfont 1.x headers bdftopcf 1.1 Emil Velikov (1): autogen.sh: use quoted string variables Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish git tag: bdftopcf-1.1 https://xorg.freedesktop.org/archive/individual/app/bdftopcf-1.1.tar.bz2 MD5: 2a455d3c02390597feb9cefb3fe97a45 bdftopcf-1.1.tar.bz2 SHA1: 48a783337a5aa49ebc102c9788ff0f43ea35c5c4 bdftopcf-1.1.tar.bz2 SHA256: 4b4df05fc53f1e98993638d6f7e178d95b31745c4568cee407e167491fd311a2 bdftopcf-1.1.tar.bz2 SHA512: 7b790e8d512ca2812ac889c156ef91c48798b4744a6857e5b17e0128764b5afa8c5426fe5de05a9819d64745116718db4221b3e657e3c2633465e87179c44bec bdftopcf-1.1.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/app/bdftopcf-1.1.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/app/bdftopcf-1.1.tar.gz MD5: faa2e00983ba5cf9ea09e2075e185286 bdftopcf-1.1.tar.gz SHA1: aaf37ba820c1878613024f4e8e1236b441476f5d bdftopcf-1.1.tar.gz SHA256: 699d1a62012035b1461c7f8e3f05a51c8bd6f28f348983249fb89bbff7309b47 bdftopcf-1.1.tar.gz SHA512: 79a9f54c829f048ec6e1f9a33fefb6ecbd715fe32fbea80b3df2ae27242eae228fd08a855f84c20267b32c58783d3a40406734cd5858c2619477f208fb84ace4 bdftopcf-1.1.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/app/bdftopcf-1.1.tar.gz.sig - ajax 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: How to specify a larger font for an application?
On Fri, 2018-05-11 at 03:06 -0500, Leslie Turriff wrote: > I normally use the X2 text editor for most of my file editing, but > although > it is an excellent editor, its default font is too small for me to read > easily, so I'm looking for a way to change that. > The editor has a configuration file with a parameter that looks like > this: > > xwindows_font: fixed > > but I haven't figured out what the possibilities are for valid font > descriptions to replace "fixed". "fixed" is an alias for "6x13", which is itself an alias for something like "-misc-fixes-medium-r-normal--13-*-*-*-*-*-*-*". You can get a complete list of the fonts available to your X server by running xlsfonts(1), or you can use the xfontsel(1) utility to select one interactively. The dropdown boxes in xfontsel map directly to the XLFD fields: https://en.wikipedia.org/wiki/X_logical_font_description - ajax ___ 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: vesa driver problem
On Mon, 2018-05-21 at 18:35 +, G. Sebastián Pedersen wrote: > May 21, 2018 6:31 PM, "Adam Jackson" <a...@nwnk.net> wrote: > > > On Mon, 2018-05-21 at 17:12 +, G. Sebastián Pedersen wrote: > > > > > [ 25.201] (II) VESA: driver for VESA chipsets: vesa > > > [ 25.201] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not > > > permitted) > > > > Pretty sure this means your X server isn't running as root, and needs > > to be. > > I tried running X as root with no luck (although don't remember if > the specific error you point disapper. Could check it when got home. > The rest remains the same, I'm pretty sure about that.) The other possibility I can think of is that your kernel has been locked down hard enough that userspace isn't allowed to access I/O ports. CONFIG_STRICT_DEVMEM might be guilty here. There's not been any changes in either xserver 1.20 or vesa 2.4.0 that should cause this, though. - ajax ___ 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: vesa driver problem
On Mon, 2018-05-21 at 17:12 +, G. Sebastián Pedersen wrote: > [25.201] (II) VESA: driver for VESA chipsets: vesa > [25.201] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not > permitted) Pretty sure this means your X server isn't running as root, and needs to be. - ajax ___ 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
[ANNOUNCE] xf86-video-mach64 6.9.6
A boring release, fixing source compatibility with xserver 1.20. Adam Jackson (3): Move max mode h/v checks into ATIValidMode mach64 6.9.6 Alan Coopersmith (2): configure: Drop AM_MAINTAINER_MODE autogen.sh: Honor NOCONFIGURE=1 Emil Velikov (2): autogen.sh: use quoted string variables xf86-video-mach64: remove the GlxSetVisualConfigs stub and friends Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish git tag: xf86-video-mach64-6.9.6 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-mach64-6.9.6.tar.bz2 MD5: 0e12f9a3b5659e1e27e03adc42b04d99 xf86-video-mach64-6.9.6.tar.bz2 SHA1: 1fdf0c3488ab88cb46b563efee166a5d54a01932 xf86-video-mach64-6.9.6.tar.bz2 SHA256: 7a0707c71bb522430f83bb5e9d9ee697e661e35534a3a2d10834f86b327a3c9c xf86-video-mach64-6.9.6.tar.bz2 SHA512: 687f6ac60491b704d5c4788463763d2f4bf725611e10bd2163156963fe0a8fdbffe0a1b7c737eff131f01759e43b5ec3544a7dabe66a67e85b286dcb969da2f1 xf86-video-mach64-6.9.6.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-mach64-6.9.6.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/driver/xf86-video-mach64-6.9.6.tar.gz MD5: 5431cbcc9cb71798c718b5d8a0fd49d5 xf86-video-mach64-6.9.6.tar.gz SHA1: 2015b02266add5b8dff50dda0e7a8932d45328d6 xf86-video-mach64-6.9.6.tar.gz SHA256: 873a9d64c7d08ca1617d98e9dd58389b948f92c052d7914922d9eed4acb2f6a4 xf86-video-mach64-6.9.6.tar.gz SHA512: 0d8bff0b59cedae79532e542438c4003d37da825909c71f86189fecbea4b71f6ab95d7d84dcc39eb3f856d92f4cba0e7974224f826686ff5449dff85f1f4d0bb xf86-video-mach64-6.9.6.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-mach64-6.9.6.tar.gz.sig - ajax ___ 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
[ANNOUNCE] xf86-video-rendition 4.2.7
A boring release, adding source compatibility with xserver 1.20. Adam Jackson (2): Move [HV]Total checks into renditionValidMode rendition 4.2.7 Alan Coopersmith (2): configure: Drop AM_MAINTAINER_MODE autogen.sh: Honor NOCONFIGURE=1 Emil Velikov (1): autogen.sh: use quoted string variables Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish git tag: xf86-video-rendition-4.2.7 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-rendition-4.2.7.tar.bz2 MD5: d21c65b68b74206a67ecc54ec0589a7c xf86-video-rendition-4.2.7.tar.bz2 SHA1: 0330d69006c5cad96a5a5448d2bdf129d4c5c8fd xf86-video-rendition-4.2.7.tar.bz2 SHA256: 9511c6595c9d489a022635bd8d91149de0cb3cbf9034739452ca5b9b5d63f87b xf86-video-rendition-4.2.7.tar.bz2 SHA512: 5a23a599488946499e9bb3dfaf553cd68b6a1555a9c46b4038f355038a28747715bb940c52170f909917386911c8ae2607c669ba28f24a6c10ad375dab4535aa xf86-video-rendition-4.2.7.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-rendition-4.2.7.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/driver/xf86-video-rendition-4.2.7.tar.gz MD5: 64223cd2f29188de81a3a7ddd2c6c3ee xf86-video-rendition-4.2.7.tar.gz SHA1: f12398c537987a15b9dbe75dc6889a0202d98a43 xf86-video-rendition-4.2.7.tar.gz SHA256: 16712fec045f5e499d32267d0cdbe89eea7ca33d8bdeed93b4874adb9b4e1bce xf86-video-rendition-4.2.7.tar.gz SHA512: 0db93e73ee596a0be58e9e2221e8568bfd7d46c91866ff568ae74318d4fd7b7571b93906015141c1c730b489f81b9805d43174bd44527a9ae15f81d4a658579b xf86-video-rendition-4.2.7.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-rendition-4.2.7.tar.gz.sig - ajax ___ 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: new dependency for libtizcore required for mesa?
On Thu, 2018-06-07 at 11:06 -0400, Dennis Clarke wrote: > Ah .. oops. Thanks for the reply and I should look closer before jumping > on the "what?" button. > > How very odd : > > root@xorg:~# apt-get install llvm > Reading package lists... Done > Building dependency tree > Reading state information... Done > llvm is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. > root@xorg:~# > > Yet my old build process fails looking for LLVM? The package named 'llvm' is just the runtime. Typically any package you need as a build dependency is going to be named llvm-dev on Debian-like systems. - ajax ___ 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
[ANNOUNCE] edid-decode has moved
I don't have the cycles to maintain edid-decode, and Hans Verkuil (who contributed a ton of HDMI-related patches) has graciously offered to take over. The project can now be found at: https://git.linuxtv.org/hverkuil/edid-decode.git/ - ajax 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: Stuck on Config Setup with IBM x3650 and CentOS7
On Tue, 2017-10-17 at 10:36 -0500, Benjammin2068 wrote: > Hey all, > > I've been playing with an old x3650 and although video has been a > little spotty, I thought it worked itself out. > > The server has a Radeon graphics on board (see included Xorg.0.log) > with VGA to the back panel and the DVI apparently goes to the RSA > (remote access) host so it can be digitized and presented remotely. > > Yesterday I had an unplanned power outage (batteries in UPS died > during outage) -- now the local video doesn't seem to boot up anymore > (no Gnome Desktop). The log given here shows X starting up normally, and several clients connecting, so whatever the problem is here it probably isn't X. From runlevel 3 you can start the X server manually with 'X -retro' to see if the classic root weave "test pattern" works. If it does work, then something in the Gnome session is failing to initialize properly; if it doesn't work then the power outage may have fried the video card. - ajax ___ 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.0.log repetitive entries
On Thu, 2017-10-19 at 20:29 -0300, sawb...@gmx.net wrote: > For example, these lines accounting for the mode setting of each one > of my three monitors: > > (II) NVIDIA(0): Setting mode "CRT-0:1280x1024" > (II) NVIDIA(1): Setting mode "DFP-0:1280x1024" > (II) NVIDIA(2): Setting mode "CRT-1:1280x1024" I'm pretty sure these messages are printed in response to configuration commands issued by the desktop session itself. So if they're being printed repeatedly, it's because your DE is doing repeated work. - ajax ___ 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
[ANNOUNCE] libpciaccess 0.14
This release adds support for 32-bit PCI domain IDs, which are apparently common in virtualized environments. This support has been tested on Linux, and probably also "just works" on FreeBSD and Solaris, to the extent that the underlying OS supports it. If you were allocating a struct pci_device yourself, or embedding it in another structure, this release would be an ABI break. That said, anyone doing this would already be violating the implicit API contract (not to mention good taste) and we were unable to find any consumers of this library misbehaving in this way. As a result the library's soname does not change in this release. Adam Jackson (1): libpciaccess 0.14 Stephen Hemminger (1): linux: support 32 bit PCI domains (v3) git tag: libpciaccess-0.14 https://xorg.freedesktop.org/archive/individual/lib/libpciaccess-0.14.tar.bz2 MD5: 8f436e151d5106a9cfaa71857a066d33 libpciaccess-0.14.tar.bz2 SHA1: f70a958bf4e744cb4ee93be64e9bc52ac05cdaeb libpciaccess-0.14.tar.bz2 SHA256: 3df543e12afd41fea8eac817e48cbfde5aed8817b81670a4e9e493bb2f5bf2a4 libpciaccess-0.14.tar.bz2 SHA512: bf40214dfd22f2a223f7c948566e6eaa4bfed60116e71b3eb19f6fe7ab2c4546649eb0416c06d5983e476ea5e27de036936646eb5f800ea97763b6d1f1976f4b libpciaccess-0.14.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/lib/libpciaccess-0.14.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/lib/libpciaccess-0.14.tar.gz MD5: 344872335233111f44504d3f7cb71bb3 libpciaccess-0.14.tar.gz SHA1: 32a8fde23da89f767c10da0a01079fcd80a0afec libpciaccess-0.14.tar.gz SHA256: 8d86e64893917be3dfb1c5e837888d1275399c818783474002203d751312b03c libpciaccess-0.14.tar.gz SHA512: dd77ac76bddd85195f52b57e32777cf9046cd4227a855f4176bdca081602be15dd46698d7f34172410f23ef4077fe345b4357d07fe96b0de1dcd053b55c40463 libpciaccess-0.14.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/lib/libpciaccess-0.14.tar.gz.sig - ajax 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: Xorg shutdown causes Slackware 14.2 to freeze completely
On Sat, 2018-01-06 at 23:34 +0100, Vitor Barbosa wrote: > My problem is that even though the x server runs quite smoothly, half > of the time I shut it down it makes the computer to freezes > completely and the system becomes unresponsive to everything. I even > trying logging using ssh from another computer to debug the problem > but the computer stops responding when the problem happens. I was not > able to identify this system freeze on any log. The X log here shows you using the vesa driver. You would almost certainly be better off using the intel driver, but your kernel appears not to support it: > Current Operating System: Linux darkstar 4.4.88 #2 SMP Thu Sep 14 14:21:06 > CDT 2017 x86_64 I think Kabylake support was added in 4.5? But we're on 4.14 by now, probably it's wise to update your kernel anyway. - ajax ___ 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
[ANNOUNCE] xorgproto 2018.2
This release fixes various version numbers and include paths, corrects an error in the RANDR specification, and adds the meson build system which was erroneously left out of 2018.1. Adam Jackson (6): meson: Fix xf86driproto.pc presentproto: Fix version number (1.1 not 1.0) kbproto: Fix version number (1.0.7 not 1.0.6) xproto: Bump to 7.0.32 autotools: Distribute the meson build system xorgproto 2018.2 Giuseppe Bilotta (1): randr: MONITORINFO has outputs, not crtcs git tag: xorgproto-2018.2 https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2018.2.tar.bz2 MD5: 490677ddbc649b177eda7ddb8d3e2074 xorgproto-2018.2.tar.bz2 SHA1: 71e3c4d94266e6022963f7be32a9160e41d4800e xorgproto-2018.2.tar.bz2 SHA256: 9709c08b65d8371637605db97247782d1f0fa0bfd2111e37999088bb11996e64 xorgproto-2018.2.tar.bz2 SHA512: 29ac0479de321eb921b1d902e4670e9e856f8b50c95c07a855aea122e5c9762ff34d01dbda9c795e4c652b09e21151f024aa7ba54bd463e14263db5240418862 xorgproto-2018.2.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2018.2.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2018.2.tar.gz MD5: f3232d78ceaf7e9d108fe61f7fd53156 xorgproto-2018.2.tar.gz SHA1: 976dd33c436de05ea11c49e7dcb96e3ff31ea6bd xorgproto-2018.2.tar.gz SHA256: 2ea043125faad276e3529cff871e835929fe28f7e2009517ff1aae8f6fc84663 xorgproto-2018.2.tar.gz SHA512: 31bff77c54e4832dbd55534b90606e49b2face0356245edd7d6028f26b06fa9e95dab63aed23d55f8552291fa384f65dde2f223b96cc705e98c425a1d0dd3d4b xorgproto-2018.2.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2018.2.tar.gz.sig - ajax ___ 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
[ANNOUNCE] xorgproto 2018.1
This package combines the protocol headers, which were formerly scattered in individual packages. At this point none of them are changing rapidly enough to justify such fine granularity, particularly when what changes do occur tend to affect multiple extensions at once (Present and DRI3 for example). The individual protocols are still installed as separate pkg-config modules, and consumers should continue to use the per-protocol package version numbers. This release includes both an autotools-based and a meson-based build system. The meson build is slightly faster and more convenient for CI and embedding, and it is expected to become the default at some point. However the autotools build is "official" at the moment, in the sense that it was used to build the release and is generally expected to work. Please report any issues you have with either one. is no longer dynamically generated according to the host platform. As a result, this release no longer makes any attempt to be compatible with pre-C89 compilation environments, which hopefully nobody would ever notice. git tag: xorgproto-2018.1 https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2018.1.tar.bz2 MD5: c110fe52f9cf7d92f4f2cd6a04840676 xorgproto-2018.1.tar.bz2 SHA1: c40c6858928dfaaf9fd7128c7927113668c85864 xorgproto-2018.1.tar.bz2 SHA256: 7eb9ea8a204499d2d7a5958db82e57a56a63eb4ff12c19ebf3bd6b82d6ac1799 xorgproto-2018.1.tar.bz2 SHA512: eaad8947f8cda4683bd952706feaa926eed06c508925d3bed7c9a610f925844d3546bbfe49b5403220ca812d63442ca6a72e65ecc50a71899aadf60875156800 xorgproto-2018.1.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2018.1.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2018.1.tar.gz MD5: 3af8cb82af512050cbadbd67a948 xorgproto-2018.1.tar.gz SHA1: efa8516bbb939eca3a2abdeee4c9a9ccffc1e059 xorgproto-2018.1.tar.gz SHA256: a386126eee0cd91ccb09117144b5b207e9d067983abfd38210ae91e377c32c49 xorgproto-2018.1.tar.gz SHA512: f9f42f0973d8f81bf7cc5f0ecef5a2aac2bd81aa182ec601a27cb46bbe5c2ec466fcd53933695d64fb0d9ce710a402ee81744392704843ddaec5f00fbf717599 xorgproto-2018.1.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2018.1.tar.gz.sig - ajax ___ 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
[ANNOUNCE] xf86-video-vesa 2.4.0
Nothing terribly exciting, but enough bug fixes to justify a release. Adam Jackson (4): Don't build old probe method on sufficiently new servers Fall back to VGA if the palette API isn't supported Use VBEFreeVBEInfo not free vesa 2.4.0 Emil Velikov (1): autogen.sh: use quoted string variables Ian Lepore (1): Honor Option "NoDDC" correctly Matthew Green (1): When debugging, print the VGAbase as well. Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish Stefan Dirsch (1): Use default refresh by default git tag: xf86-video-vesa-2.4.0 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.4.0.tar.bz2 MD5: 8134201beaf6f77150c7809c3cc802e6 xf86-video-vesa-2.4.0.tar.bz2 SHA1: 99b69044c34292ba062e365c07dcd024462e794b xf86-video-vesa-2.4.0.tar.bz2 SHA256: bf443c94d7bf6cd4e248f8a3147f4647be04dc4c80250d9405006263bbdee38c xf86-video-vesa-2.4.0.tar.bz2 SHA512: 4af5c0a7fd64eba503980198cf510688dff2f33482ceac446455d97255dcc828613387ac57828eb6dce080cb15a8644a2b2e278bf356705fdeaea873ab07c2de xf86-video-vesa-2.4.0.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.4.0.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.4.0.tar.gz MD5: 939a12453b93d68d374041f2206cbdaa xf86-video-vesa-2.4.0.tar.gz SHA1: f54e917f14eafa7237f5a7148f8804b827851485 xf86-video-vesa-2.4.0.tar.gz SHA256: 2982dd4eaf649101bd2c0dde37151a65157f6cbe120a692e6a6de764e36e03ea xf86-video-vesa-2.4.0.tar.gz SHA512: d3528a725ae49b85ba499f9657b47bb3032669daab6c6aef7d8c97b78a475082f6532a888fc1bef0354a8e0e55b513a5d5d6d108a2e42bb713872674ae7c1dcd xf86-video-vesa-2.4.0.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-vesa-2.4.0.tar.gz.sig - ajax ___ 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
[ANNOUNCE] xorg-server 1.19.6
Yet another collection of fixes from master. There will likely be at least one more 1.19.x release in 2018 as there are still a number of unreviewed patches pending. Until then, happy new year. Adam Jackson (10): xfixes: Remove the CursorCurrent array glx: Fix typos that break GLX_ARB_context_flush_control glx: Only flush indirect contexts in MakeCurrent (v2) glx: Fix glXQueryContext for GLX_FBCONFIG_ID and GLX_RENDER_TYPE (v2) composite: Remove a misleading comment composite: Export compIsAlternateVisual composite: Make compIsAlternateVisual safe even if Composite is off glx: Send GLX_VISUAL_SELECT_GROUP_SGIX attribute for visuals glx: Move Composite's synthetic visuals to a different select group xserver 1.19.6 Alex Goins (1): ramdac: Check ScreenPriv != NULL in xf86ScreenSetCursor() Daniel Martin (4): modesetting: Fix potential buffer overflow test: input: Fix used uninitialized warning in dix_event_to_core test: signal-logging: Fix looping signed number tests os/xdmcp: Honour -once when session is dead Eric Anholt (1): xkb: Print the xkbcomp path being executed when we fail to compile. Giuseppe Bilotta (3): xkb: initialize tsyms randr: ProcRRGetOutputInfo: initialize memory randr: rrGetScreenResources: initialize memory Hector Martin (1): edid: fix off-by-one error in CEA mode numbering Michel Dänzer (1): present: Only send PresentCompleteNotify events to the presenting client Nikolay Martynov (1): XShmGetImage: fix censoring Olivier Fourdan (2): xwayland: Fix non-argb cursor conversion dix: avoid deferencing NULL PtrCtrl Peter Hutterer (1): config/udev: consider ID_INPUT_FOO=0 as 'unset' Thomas Hellstrom (3): glx: Work around a GLX_OML swap method in older dri drivers glx: Fix visual fbconfig matching with respect to swap method glx: Duplicate relevant fbconfigs for compositing visuals Tomasz Śniatowski (1): os: Fix strtok/free crash in ComputeLocalClient git tag: xorg-server-1.19.6 https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.6.tar.bz2 MD5: 3e4ff034a331aed2322b078694a8 xorg-server-1.19.6.tar.bz2 SHA1: 2dd560ac49bdbda7f67166546af43541fabf517f xorg-server-1.19.6.tar.bz2 SHA256: a732502f1db000cf36a376cd0c010ffdbf32ecdd7f1fa08ba7f5bdf9601cc197 xorg-server-1.19.6.tar.bz2 SHA512: 38519a8d0af9dd034045fc346959496dd718fa59b6188307974797a1cd9c349deb54987f6232ea8396baf810dcc710c0ff191f76ed2186cae4d44921b3680412 xorg-server-1.19.6.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.6.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.6.tar.gz MD5: ada013becbe850b92e2a8433dfb2cfe6 xorg-server-1.19.6.tar.gz SHA1: f58b318bd17fe3af41ebf32d5a22da5dc667009e xorg-server-1.19.6.tar.gz SHA256: 3c0e4a354a6b1d5d357b121357946ee8ffdb2f52158b2e63e105be9cef013168 xorg-server-1.19.6.tar.gz SHA512: 0ee9e7a20bac7b3a9a7730fc453a8b1f146e36f774721c7f69f723976c5cb456b18ce27bba71605995a8fc087518e462f06deb52f5145b87f28397f8e2cc1210 xorg-server-1.19.6.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.6.tar.gz.sig - ajax 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
[ANNOUNCE] xf86-video-v4l 0.3.0
This long overdue release features build compatibility with newer X servers and support for v4l2 devices. Adam Jackson (6): Remove call to LoaderGetOS Remove a bogus memset Fix distcheck v4l 0.3.0 Alan Coopersmith (2): Remove xorgconfig & xorgcfg from See Also list in man page Update Sun license notices to current X.Org standard form Cyril Brulebois (1): Bump version for development. Gaetan Nadon (18): .gitignore: use common defaults with custom section # 24239 .gitignore: use common defaults with custom section # 24239 Several driver modules do not have a ChangeLog target in Makefile.am #23814 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES configure.ac: remove unused sdkdir=$(pkg-config...) statement config: header files are part of the source not in EXTRA_DIST config: upgrade to util-macros 1.8 for additional man page support config: update AC_PREREQ statement to 2.60 config: remove AC_PROG_CC as it overrides AC_PROG_C_C99 config: remove unrequired AC_HEADER_STDC config: remove unrequired AC_SUBST([XORG_CFLAGS]) config: complete AC_INIT m4 quoting config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: replace deprecated AC_HELP_STRING with AS_HELP_STRING config: replace deprecated use of AC_OUTPUT with AC_CONFIG_FILES config: add comments for main statements Hans de Goede (1): Fix build post xserver 1.17 Julien Cristau (1): Add missing includes. Mauro Carvalho Chehab (8): Port xf86-video-v4l driver to V4L2 Coding style Cleanup Use the fourcc header instead of redefining it inside the code Fix Get/Set Port Attribute logic Return BadMatch if a Port Attribute is not found Provide a more consistent message if FBUF fails Fix arguments for v4l_check_yuv Fix standard video size detection Mihail Konev (1): autogen: add default patch prefix git tag: xf86-video-v4l-0.3.0 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-v4l-0.3.0.tar.bz2 MD5: 167b82a486859dafd076ec0ab12d7d40 xf86-video-v4l-0.3.0.tar.bz2 SHA1: e29308282fd2f12626e2582d07f9c932804b25d3 xf86-video-v4l-0.3.0.tar.bz2 SHA256: e5fcb23bc1f51d883f9ab1f371af892990c1599cdbda2deaabe2f8adc8259d20 xf86-video-v4l-0.3.0.tar.bz2 SHA512: ec39b2fa70143b8662c3bd8ec094afdfa245687072d19164eb6b6c3e96aaf39a4d7708af60be975fcd07927cc9055812a67abb611a98cd27b3d548d8c2249955 xf86-video-v4l-0.3.0.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-v4l-0.3.0.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/driver/xf86-video-v4l-0.3.0.tar.gz MD5: ac562e4d955b74e91a8ef22d8c87e605 xf86-video-v4l-0.3.0.tar.gz SHA1: abdd3450552137998a196fb6c1efcca1e496c8a3 xf86-video-v4l-0.3.0.tar.gz SHA256: cbaa8ba208b62da0b6da7f463ee80fefe239ec9e31949ef08b6677734a9a319e xf86-video-v4l-0.3.0.tar.gz SHA512: f695417f80339845708edd13a3fa997953bf8559f2b288b56e27ce32cc6efc511f59bc73d17b50457136d734ec993e728cf7311d34d6fd6dfa856381c799e242 xf86-video-v4l-0.3.0.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-v4l-0.3.0.tar.gz.sig - ajax 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 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 ___ 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: vesa module's name for its exposed video port?
On Thu, 2018-09-06 at 16:39 +, m...@crcomp.net wrote: > Greetings, > > A grep of Xorg.0.log [1] seems to indicate that only the vesa driver is > loaded and then used by X on my PC. > On the other hand, when the intel driver loads on my laptop with an > external VGA port, the intel driver uses VGA as the name for the exposed > port. You can then use Identifier "VGA" [2] to override the EDID, which > the X probe returns. > What's the name that the vesa module uses for its exposed video > port? (It's the vesa port name that needs to appear in xorg.conf in > order to force a mode.) This is misguided in a couple of ways. The automatic matching of Monitor sections by output name is only done for RANDR-1.2-capable drivers, which vesa is not. For vesa-like drivers, if there's only one Monitor section in the config file, it will be used (iirc). Otherwise, one names the monitor whatever one wants, and simply names it again in the Device section to bind the two together, a la: Section "Monitor" Identifier "Spartacus" # ... EndSection Section "Device" Identifier "default" Driver "vesa" Monitor "Spartacus" EndSection That said: vesa, among its many other limitations, can't set arbitrary modes. If the mode isn't pre-programmed into the video BIOS, it's not available, and no amount of xorg.conf is going to save you. The complete X log would give more clues about what modes are available and why you're not getting the ones you want, but you're almost certainly better off figuring out why the intel driver isn't working for you (which the X log probably also has some hints about). - ajax ___ 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
[ANNOUNCE] libXScrnSaver 1.2.3
Fixes a 25+-year-old bug in correctly filling in the ::root member of the ScreenSaverNotify event. Adam Jackson (1): libXScrnSaver 1.2.3 Alan Coopersmith (3): Copy root field from wire event into root, not window, of Xlib event configure: Drop AM_MAINTAINER_MODE autogen.sh: Honor NOCONFIGURE=1 Daniel Martin (1): Fix typo in man page: XScreenSaverSaverRegister() Emil Velikov (1): autogen.sh: use quoted string variables Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish git tag: libXScrnSaver-1.2.3 https://xorg.freedesktop.org/archive/individual/lib/libXScrnSaver-1.2.3.tar.bz2 MD5: eeea9d5af3e6c143d0ea1721d27a5e49 libXScrnSaver-1.2.3.tar.bz2 SHA1: 70c791c5755a298ecf1a0823e239a24fa4b2b42f libXScrnSaver-1.2.3.tar.bz2 SHA256: f917075a1b7b5a38d67a8b0238eaab14acd2557679835b154cf2bca576e89bf8 libXScrnSaver-1.2.3.tar.bz2 SHA512: 7ea628324a11b25ee82c7b11c6bf98f37de219354de51c1e29467b5de422669ba1ab121f3b9dc674093c8f3960e93c5d5428122f5539092f79bc8451c768354a libXScrnSaver-1.2.3.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/lib/libXScrnSaver-1.2.3.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/lib/libXScrnSaver-1.2.3.tar.gz MD5: 6ae51eb64351e11cea281f3a331ac461 libXScrnSaver-1.2.3.tar.gz SHA1: 15c702b97dc95019b7d49116601673a0d9850d6e libXScrnSaver-1.2.3.tar.gz SHA256: 4f74e7e412144591d8e0616db27f433cfc9f45aae6669c6c4bb03e6bf9be809a libXScrnSaver-1.2.3.tar.gz SHA512: 8f0d1d460027acfd50a312bf3b10407959d5ccbd9e76b319563535ba9038e1195cf0493664f80fd86e61ed037593d43e7b9a4f8f5d1f0c719d42935bf74ad68f libXScrnSaver-1.2.3.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/lib/libXScrnSaver-1.2.3.tar.gz.sig - ajax ___ 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
[ANNOUNCE] libXinerama 1.1.4
Contains some tiny bugfixes sitting in git unreleased for too long. Adam Jackson (1): libXinerama 1.1.4 Emil Velikov (1): autogen.sh: use quoted string variables Michael Joost (1): Remove fallback for _XEatDataWords, require libX11 1.6 for it Mihail Konev (1): autogen: add default patch prefix Peter Hutterer (1): autogen.sh: use exec instead of waiting for configure to finish Tobias Stoeckmann (1): libXinerama: Set number of screens to 0 on error git tag: libXinerama-1.1.4 https://xorg.freedesktop.org/archive/individual/lib/libXinerama-1.1.4.tar.bz2 MD5: 0d5f826a197dae74da67af4a9ef35885 libXinerama-1.1.4.tar.bz2 SHA1: 34a1d9908ffbd46805d2357c6b05f5e341a8dc7c libXinerama-1.1.4.tar.bz2 SHA256: 0008dbd7ecf717e1e507eed1856ab0d9cf946d03201b85d5dcf61489bb02d720 libXinerama-1.1.4.tar.bz2 SHA512: cff777ad942614fbf6bc6d8529f399e62debf3ecbf6cc0694a94e38c022bf929ffd5636fb59f55533c394d89b23af3ea51fa5128927f12a85787e16239330f14 libXinerama-1.1.4.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/lib/libXinerama-1.1.4.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/lib/libXinerama-1.1.4.tar.gz MD5: 416f5afc64b8d064187b3508081dd194 libXinerama-1.1.4.tar.gz SHA1: 5d9b9e6a8f92c4588b69c2e5d9597e153f443280 libXinerama-1.1.4.tar.gz SHA256: 64de45e18cc76b8e703cb09b3c9d28bd16e3d05d5cd99f2d630de2d62c3acc18 libXinerama-1.1.4.tar.gz SHA512: fa2cc45214cc591da8867dcd7e332312e8d224c390912dc8580f8b15c3c9d8ffc797eee97c20263faf129fbfc6b0d931b6bf10dc04b8ec439b852451886eba75 libXinerama-1.1.4.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/lib/libXinerama-1.1.4.tar.gz.sig - ajax 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
[ANNOUNCE] libXxf86misc 1.0.4
Several error paths in this library would fail to unlock libX11 when they returned, which would eventually cause the client to deadlock. This release fixes that bug. Adam Jackson (1): libXxf86misc 1.0.4 Alan Coopersmith (3): Strip trailing whitespace configure: Drop AM_MAINTAINER_MODE autogen.sh: Honor NOCONFIGURE=1 Egbert Eich (1): Add missing UnlockDisplay() and SyncHandle() to some error paths. git tag: libXxf86misc-1.0.4 https://xorg.freedesktop.org/archive/individual/lib/libXxf86misc-1.0.4.tar.bz2 MD5: 37ad70f8b53b94b550f9290be97fbe2d libXxf86misc-1.0.4.tar.bz2 SHA1: 2676f1b0df7ca3ed1e01a0a51420c27c25737d02 libXxf86misc-1.0.4.tar.bz2 SHA256: a89c03e2b0f16239d67a2031b9003f31b5a686106bbdb3c797fb88ae472af380 libXxf86misc-1.0.4.tar.bz2 SHA512: 1dbd51a51188a060f676b88e5d98809ea355f69933972ceb7721c83289b5bb94c1f7b889baa83209a5ed864e67dd8a4ed62f1393634e97cc99ce36a2cef447fb libXxf86misc-1.0.4.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/lib/libXxf86misc-1.0.4.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/lib/libXxf86misc-1.0.4.tar.gz MD5: 44d31e4e7feec6255c98da58523a9bcc libXxf86misc-1.0.4.tar.gz SHA1: a197c7df008aa362cd6db53bd5a6956b4d67fb3b libXxf86misc-1.0.4.tar.gz SHA256: 63a68b2fafd03236f9b0135de21976e9194d6d811ca2fd774c13a6b4be576676 libXxf86misc-1.0.4.tar.gz SHA512: 34309e581988eed3417922bd703568873566e170195ad52a89dad70b055101cb254732ecef81ecd2109c6f7529638c00a09b38db1b3b34a84ed8863a2ee5fd2d libXxf86misc-1.0.4.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/lib/libXxf86misc-1.0.4.tar.gz.sig - ajax ___ 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: How to detect (subscribe to) messages that causes screen repaint
On Thu, 2018-07-05 at 20:06 +0200, Nikola Radovanovic wrote: > Hello, > Can someone please point me to some documentation/samples on how to > do the following: > > I have to detect events (messages) that are issued when any of > attached screens (one or possibly more of them) will be repainted > (partially or completely). So any key press, new window, resize > window, mouse move etc. For updated window content, you want the Damage extension's events. X doesn't have globally-available events for mouse motion though, sorry. > What I am trying is to write a simple VNC viewer (server) for > Linux/Android and I have not yet managed to figure out how to > subscribe to such events in order to get 'paint' message and affected > rectangular area. I mean, tigervnc already exists, but sure, write another one, why not. Do consider reading it though, unix/x0vncserver/*.cxx is pretty much what you're describing, including examples of how to register for and parse Damage events. - ajax ___ 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 will not start on a Thinkpad 240 using neomagic
On Wed, 2018-01-24 at 01:12 +, Alex Bowden wrote: > Hi all, > > I have a Thinkpad 240 with a Neomagic NM2160 and I keep having an issue > with the neomagic driver. I think I have narrowed it down to the kernel > refusing to mmap the framebuffer. I created a program called testneo.c > to attempt to use pci_device_map_range to access the framebuffer but > it always returns 22 (Invalid argument). I'm not sure why that would fail, but... > [root@tpad ~]# ./testneo > neomagic nm2160 found >phys_base: 0xfd00 phys_len: 0x0100 > attempt pci_device_map_range of 2MB (0x20) // from neo_driver.c Does mapping the whole BAR work? If so it'd be trivial to change the driver to just do that instead, and it should be harmless. - ajax ___ 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
[ANNOUNCE] xserver 1.20 RC1
This is the first release candidate for xserver 1.20. Notable changes since 1.19 include: - RANDR 1.6, which enables leasing RANDR resources to a client for its exclusive use (e.g. head mounted displays) - Depth 30 support in glamor and the modesetting driver - A meson-based build system, parallel to autotools - Pageflipping support for PRIME output sinks - OutputClass device matching for xorg.conf - Input grab and tablet support in Xwayland ... and the usual pile of bug fixes and cleanups. The final release will include a more complete set of release notes. I expect to push these out roughly weekly as things stabilize. With any luck RC3 will be the final release candidate, with the actual release around March 20. The server is ABI-frozen until 1.21 development opens; external modules should rebuild against this server and report any issues. Full changelog since 1.19.0: Aaron Plattner (1): randr: Use RRTransformEqual in RRCrtcPendingTransform Adam Jackson (196): configure: Enable glamor when building just Xwayland composite: Fix repaint of borders (v2) dix: Rename (and retype) PixmapPerDepth[1] to defaultStipple dix: Clear graphicsExposures for scratch GCs in one place shadowfb: Rename this particular shadow.c to shadowfb.c shadow: Lift 32->24 conversion from modesetting to dix shadow: Remove indirection stubs shadow: Macro cleanup shadow: Remove unused shadowAlloc Revert "damage: Make damageRegionProcessPending take a damage not a drawable" glamor: Squash unused variable warning Revert "tests: fix --disable-xorg build" dmx: Remove non-evdev hardware input drivers kdrive: Remove non-evdev input drivers composite: Remove a misleading comment composite: Export compIsAlternateVisual glx: Send GLX_VISUAL_SELECT_GROUP_SGIX attribute for visuals glx: Move Composite's synthetic visuals to a different select group loader: Port from xfree86 to dix API loader: Remove *GetOS loader: Don't add internal/ to the search path loader: Include fewer headers from xf86Module.h loader: Remove unused loader error codes and dead enum loader: Remove silly "unspecified" version handling xfree86: Remove DriverRec1 compat struct xfree86: Fix up some bad indentation xfree86: Remove a stray reference to font modules loader: Move loader list details to internal header loader: Turn LoaderListDirs into LoaderListDir loader: Remove unused arguments from LoadModule loader: Remove unused path and name from ModuleDescPtr loader: Learn about the joy of snprintf dri1: Remove some dead event code xfree86: Bump video ABI to 24.0 xfree86: Fix a comment about ScrnInfoRec xfree86: Remove max[HV]Value from ScrnInfoRec xfree86: Drop virtualFrom from ScrnInfoRec xfree86: Remove Option "BiosBase" (v2) xfree86: Remove memClk from ScrnInfoRec xfree86: Remove unused chipID/Rev from ScrnInfoRec xfree86: Reorganize the reserved ScrnInfoRec slots wfb: Add missing rename for fbGlyphs wfb: Hide init function decls behind FB_ACCESS_WRAPPER fb: Remove unused fbGetFreeCompClip macro fb: Remove stray references to fbHasVisualTypes mi: Add include guards to migc.h dix: Pass the whole property into deliverPropertyNotifyEvent dix: Add a callback chain for window property state change vfb: Bump default depth to 24 dispatch: Mark swapped dispatch as _X_COLD sdksyms: Tighten up the symbols we add to the magic table xfake: Remove xfbdev: Remove kdrive: Remove now-unused linux backend miarc: Style cleanup for miWideArc miarc: Make the caller free the arc span data miarc: "Cache" arc span data for dashed arcs os: Squash missing declaration warning for timingsafe_memcmp test: Fix distcheck failures parser: Fix crash when xf86nameCompare(s1 = x, s2 = NULL) xinerama: Implement graphics exposures for window->pixmap copies (v4) Revert "sdksyms: Tighten up the symbols we add to the magic table" ephyr: Don't clobber bitsPerPixel when using glamor xfree86: Remove 24bpp pixmap format support (v2) fb: Remove 24bpp support (v3) fb: Handle ZPixmap planemask in GetImage the other way around glamor: Avoid software fallback for planemasked ZPixmap GetImage dix: Remove PRIVATE_DAMAGE glx: Fix MakeCurrent with no drawables xfree86: Clean up DPMS support dix: Lift DPMS to a screen hook dpms: Consolidate a bunch of stuff into Xext/dpms.c xfree86: Remove driver entity hooks and private glx: Remove enter/leave server API xephyr: Check for host XVideo support before trying to use it meson: Fix a typo meson: Factor out the AC_REPLACE_FUNCS stuff to its
Re: XRandr adaptive mirrored screens
On Mon, 2018-04-09 at 18:25 +0200, Prunk Dump wrote: > Is there a way to make Xorg mirror screens by default and choose > itself the best resolution ? Ideally a config file that I can deploy > in all my teacher's station. In the upcoming 1.20 release there is a feature for this, Option "PreferCloneMode" in xorg.conf. - ajax ___ 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
[ANNOUNCE] xorg-server 1.19.99.904
Another batch of cleanups and fixes, mostly in glamor and DRI3. At this point the only outstanding major feature for 1.20 that hasn't landed yet is EGLStreams support for Xwayland. The patches require some minor rebasing to account for per-window flips in Present, I'll post that momentarily I suppose. I'm honestly of two minds about merging it, the deafening silence of review feedback has not been encouraging. Aaron Plattner (1): xfree86: Restore newline before "X Protocol Version" string Adam Jackson (10): gtf: Warning fix dmx: Fix some snprintf warnings. dmx: Fix a read-from-uninitialized warning dmx: Clean up some argument parsing code dmx: Silence a string truncation warning. xkb: Silence some compiler warnings mi: Hush an almost certainly bogus warning dix: Hush an almost certainly bogus warning xwayland: Silence a build warning if we can xserver 1.20 RC4 Daniel Stone (10): dri3: Use single-FD screen call for single-FD request drmmode: Track if BO allocation used modifiers glamor: Track if BO allocation used modifiers glamor: Push make_exportable into callers glamor: Reallocate pixmap storage without modifiers if necessary glamor: Fall back to non-modifier allocations glamor: Add fd_from_pixmap hook modesetting: Don't reuse iterator in nested loop dri3: Set stride and size for old clients modesetting: Actually get framebuffer ID Emil Velikov (10): dri3: annotate the dri3_screen_info data as const xwayland: don't close() fds we don't own dri3: annotate fds/strides/offsets arrays as const dri3: simplify dri3_open() implementation xwayland: zero num_modifiers from the start glamor: zero num_modifiers from the start dri3: check for ::get_drawable_modifiers failure xwayland: zero num_formats from the start glamor: zero num_formats from the start dri3: rework format/modifier caching Jon Turney (1): hw/xwin/glx: Allocate fbconfigs correctly Kyle Brenneman (1): GLX: Fix a use after free error with the GLVND vendor handle. Louis-Francis Ratté-Boulianne (2): modesetting: Use atomic modesetting to set DPMS mode modesetting: Have consistent state when using atomic modesetting Mario Kleiner (1): modesetting: Fix page flipping harder under DRI 3.2. Michal Srb (2): glx: Do not call into Composite if it is disabled. Xext: Fix memory leaks in hashtable. Peter Hutterer (1): xfree86: drop KDSKBMUTE handling Samuel Thibault (1): dix: always send focus event on grab change git tag: xorg-server-1.19.99.904 https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.904.tar.bz2 MD5: b7623726287e405ed03b9e27f0811f87 xorg-server-1.19.99.904.tar.bz2 SHA1: 5bfe19ab814ab8b973c0c4b53547de4e951d3679 xorg-server-1.19.99.904.tar.bz2 SHA256: 0ec3bb260c3798964d413db4238485fca5cab774a9d279c04e5272202f8e58b8 xorg-server-1.19.99.904.tar.bz2 SHA512: b9dccc777d0a30c6b40bddffe1f359dde4103539c6598f04bf8cf5f59e6770229221a199c1866b4eba0cf8d2d87fe878985bbd2e3c6ec5b65e3f16195ea8d57e xorg-server-1.19.99.904.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.904.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.904.tar.gz MD5: f5082147af9822ade469f808c420a121 xorg-server-1.19.99.904.tar.gz SHA1: c481217424beb1e0f0d38d98dfc4c194a1631354 xorg-server-1.19.99.904.tar.gz SHA256: f1fe5e27d0eab494a4eea11a075f8f6d3989c3683c22e0bdf5c060e57d351c0f xorg-server-1.19.99.904.tar.gz SHA512: dad39ecc6f8a99a74191d542709d03a14415f1065f8f2c8c68ad87d3fb7c3392eaf3ff97d90827f53d2c16e0e5acbaaa0f3bf580f60615c3f35b40965f23 xorg-server-1.19.99.904.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.904.tar.gz.sig - ajax ___ 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-window crashes
On Wed, 2018-04-11 at 13:12 -0700, Alan Coopersmith wrote: > On 04/10/18 01:52 PM, alexander@wellsfargo.com wrote: > > > > flexSA14523.log:The program 'flextrdr_gtk' received an X Window System > > error. > > > > flexSA14523.log-This probably reflects a bug in the program. > > > > flexSA14523.log-The error was 'BadLength (poly request too large or internal > > Xlib length erro'. > > > > flexSA14523.log- (Details: serial 28147239 error_code 16 request_code 32 > > minor_code 0) > > Basically it's telling you there's a bug in flextrdr_gtk in which it's > doing something that results in a call to UngrabKeyboard with an > invalid argument. That's likely to be a call from your program to > something in the gtk toolkit that in turn makes that call. BadLength though? If it was an invalid argument you'd get BadValue. And UngrabKeyboard is a fixed-length request, we're never going to put it on the wire with the wrong length if you call XUngrabKeyboard(). I'd suspect that the _previous_ request had a bad length, shorter than the data actually written, and the data at the end is misinterpreted as a (malformed) UngrabKeyboard request. It would be interesting to use xscope or wireshark or whatever to see what the last requests written are. - ajax ___ 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
[ANNOUNCE] xorg-server 1.19.99.905
More bugfixes, and streams support for Xwayland. This will almost certainly be the last RC. Adam Jackson (10): sdksyms: Skip empty symbols xwayland: Don't crash on WarpPointer(dest_w = None) modesetting: Fix inverted check in dri2 WaitMSC animcur: Fix crash when removing a master device dix: Factor out extension availability check dix: Allow an extension to disable itself vnd: Disable GLX if no vendors successfully initialized glx: Require depth > 12 for GLX visuals vfb: Fix man page in re depth xserver 1.20 RC5 Chris Wilson (1): os/WaitFor: Check timers on every iteration Daniel Stone (1): dri3: Don't call vfuncs on old DRI3 screens David Woodhouse (1): glamor: fix glamor_xv_query_image_attributes() for odd-width images Emil Velikov (1): configure.ac: make use of wayland-scanner.pc Lyude Paul (5): meson: Ensure we always build Xext/hashtable.c for glx meson: Fix indenting in glx/meson.build xwayland: Decouple GBM from glamor xwayland: Add xwayland-config.h xwayland: Add glamor egl_backend for EGLStreams Mario Kleiner (2): dri3: Fix dri3_buffers_from_pixmap request. modesetting: Only use modifiers on kms drivers which do support them. Matt Turner (1): modesetting: Move GBM code inside #ifdef GLAMOR_HAS_GBM Olivier Fourdan (3): xwayland: Fix build without glamor xwayland: avoid using freed xwl_window on unrealize xwayland: Clean up all frame callbacks Thomas Klausner (1): sdksyms: Cope with __pid_t and __uint32_t git tag: xorg-server-1.19.99.905 https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.905.tar.bz2 MD5: 9be2bf4bc611789b61fa1073810f1030 xorg-server-1.19.99.905.tar.bz2 SHA1: 03db7ca162a907debb8230e207a02274a711c17e xorg-server-1.19.99.905.tar.bz2 SHA256: f73c33d70d8b52db142e0d796be98953308f68fb7625084ae15a2d46b5cc628e xorg-server-1.19.99.905.tar.bz2 SHA512: 9a6f173835989f7562debfbadae0077d75e35bfad5be1f78931fe46ac43df20591162950b27e2c813fd857114f98247be28d357566e45e5d3ac6b60873d94466 xorg-server-1.19.99.905.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.905.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.905.tar.gz MD5: bc4df37dc28e97865a7328c8cebf1b56 xorg-server-1.19.99.905.tar.gz SHA1: 067fccc3687711a9b46a45e2c97bbf41e0b242d5 xorg-server-1.19.99.905.tar.gz SHA256: 0df18d38805a8e1735480cbe6479193dbb221e66b5f766461fca160ebaf18ac9 xorg-server-1.19.99.905.tar.gz SHA512: a570df74e75ad259bef7a72620cd33dbd58d145d843adc74c699ca32b0d352d2d4d29003882f28a7ecf75a890abe2d5423cda5c2d8f22cf61804d53d7b172156 xorg-server-1.19.99.905.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.905.tar.gz.sig - ajax 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
[ANNOUNCE] xorg-server 1.19.99.902
This merges the DRI3 1.2 support (with an asterisk) and per-window
flips for Xwayland, along with the usual collection of miscellaneous
fixes. In particular the meson build is much closer to production-
ready. The asterisk for DRI3 is that the modesetting driver has some
known issues still, so the code to enable planes and modifiers is
hidden behind an xorg.conf option:
Section "ServerFlags"
Option "Debug" "dmabuf_capable"
EndSection
Thanks to all for testing and debugging.
Adam Jackson (30):
randr: Fix a crash on initialization with GPU screens
os: Define {ReadFdFrom,WriteFdTo}Client unconditionally
travis: Switch linux build from stretch to rawhide
travis: Update OSX build
appveyor: Switch to xorgproto
ci: Ignore builds for branches aimed at other CI services
meson: Add the x(org)proto headers to the include path
appveyor: use meson
travis: Bump rawhide image
travis: Drop Xcode 8.2
modesetting: Fix up some XXX from removing GLAMOR_HAS_DRM_*
autotools: Stop caring about XORG_DATE
man: s/__/@/g
meson: Add libdrm to hw/xfree86/common's dependencies
meson: Fix installing protocol.txt
meson: Build Xorg suid wrapper
meson: Install man pages
meson: Build cvt and gtf
meson: Install the dmx utilities
meson: Generate xorg-server.pc
meson: Install xorg-server.m4
meson: Fix install path for 10-quirks.conf
autotools: Fix excessive \-escaping that broke the build
suid touchup
Revert "suid touchup"
meson: Add option to set default font path (v2)
xfree86: Add Option "Debug" to ServerFlags
glamor: Hide new DRI behind Option "Debug" "dmabuf_capable"
autotools: Derive xkb configuration from xkbcomp.pc
xserver 1.20 RC2
Alan Coopersmith (1):
Revert "modesetting: Remove #ifdefs XF86_PDEV_SERVER_FD"
Alexander Volkov (1):
Xext/shm: Downgrade from error to debug log output about success
Antoine Martin (1):
os: Fix -logfile when used with -displayfd
Daniel Stone (1):
modesetting/drmmode: Remove unused flink call
Emil Velikov (7):
present: cap the version returned to the client
dri3: cap the version returned to the client
configure: remove libdrm version check
Remove always true GLAMOR_HAS_DRM_* guards
modesetting: remove always true defined(DRM_CAP_PRIME) guards
modesetting: remove always true DRM_IOCTL_CRTC_QUEUE_SEQUENCE guard
modesetting: remove fallback DRM_CAP_* defines
Eric Engestrom (1):
exa: promise not to touch the data when swapping pointers
Jon Turney (1):
meson: Require libdrm for dri1/2/3 when configured 'auto' as well as
'true'
Keith Packard (2):
Require libdrm 2.4.89 or newer
Xext/saver: Swap ScreenSaverSuspend 'suspend' field. Handle old XCB
clients.
Kyle Brenneman (1):
Don't delete GLX's extensionInitCallback list during a reset.
Laurent Carlier (4):
meson: Make APM support optional
meson: Make ACPI support optional
meson: get rid of useless HAVE_SYSV_IPC
meson: Make SHM extension optional
Louis-Francis Ratté-Boulianne (12):
dri3: Add multi-planar/modifier buffer requests
present: Send PresentCompleteModeSuboptimalCopy appropriately
modesetting: Use atomic modesetting API for pageflip if available
modesetting: Add support for multi-plane pixmaps when page-flipping
modesetting: Use atomic modesetting to configure output/CRTCs
modesetting: Get supported formats/modifiers for scanout
modesetting: Create scanout buffers using supported modifiers
modesetting: Check if buffer format is supported when flipping
glamor: Implement PixmapFromBuffers and BuffersFromPixmap
glamor: Implement GetSupportedModifiers
glamor: Use gbm_bo_create_with_modifiers for internal pixmap allocation
dri3: Enable DRI3 version 1.2
Mario Kleiner (2):
glamor/xwayland: Add depth 30 format mapping for DRI 3.2 as well.
modesetting: Fix page flipping under DRI 3.2.
Michel Dänzer (2):
glamor: Restore glamor_fd_from_pixmap and glamor_pixmap_from_fd
randr: Initialize RROuptutRec::nonDesktop
Nicolai Hähnle (4):
os: move xf86PrivsElevated here
os: use PrivsElevated instead of a manual check
xfree86: replace all uses of xf86PrivsElevated with PrivsElevated
glx: honor LIBGL_DRIVERS_PATH when loading DRI drivers
Olivier Fourdan (1):
automake: Fix 'make dist'
Rodrigo Vivi (1):
dri2: Sync i965_pci_ids.h from Mesa.
Roman Gilg (23):
present: Move screen flip functionality in separate file
present: Preliminary internal flip mode API
present: Move vblank functionality in seperate file
present: Add flip mode API hooks for several functions
present: Refactor execute in separate file
present:
[ANNOUNCE] xorg-server 1.19.99.903
Fixes for meson, modesetting, and a crash I introduced right before RC2. Adam Jackson (1): xserver 1.20 RC3 Emil Velikov (2): docs: purge some ISA references docs: remove resource management references Louis-Francis Ratté-Boulianne (2): modesetting: Ignore alpha channel when importing BOs for modesetting modesetting: Fix reported size when using atomic modesetting Olivier Fourdan (1): modesetting: Use actual crtc position for pageflip Thierry Reding (3): meson: Remove usage of pkg-config --variable=includedir meson: Distribute more SDK headers meson: Add pixman-1 to required modules in xorg-server.pc Tobias Klausmann (2): glamor: sanitze handling of "Debug" Option for "dmabuf_capable" modesetting/drmmode: add NULL pointer check in drmmode_output_dpms git tag: xorg-server-1.19.99.903 https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.903.tar.bz2 MD5: 514ca5990c32a9530985e0fc1dd1d29b xorg-server-1.19.99.903.tar.bz2 SHA1: e9bcc93b67786a5809529c74d44b07243de02863 xorg-server-1.19.99.903.tar.bz2 SHA256: 84e0895ce72b127cfded4c9c18201a94c806dd53af9c135edcd59947eac1d070 xorg-server-1.19.99.903.tar.bz2 SHA512: 6884d7a477fdab118d61ed22d264d7ee03117673fdd40e63bc1eccc5109f23a058c9a1fc08aa9215b2c7fe1e6a677adfde4aadc1cbbec559b3edc024baf87444 xorg-server-1.19.99.903.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.903.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.903.tar.gz MD5: e36ad67defece8a98f05bbe4fbe32976 xorg-server-1.19.99.903.tar.gz SHA1: 420f54771fac106eafaa56ce9d5066babbbde652 xorg-server-1.19.99.903.tar.gz SHA256: 9cfcb585a8b84b657456d445f1c5ad521fa461bdcf06e009f1ae4e625eba6529 xorg-server-1.19.99.903.tar.gz SHA512: 9707f9d3f370ead127140dc36ce9e665827676255eb5e91940f31d2065f1b0760f973a23dafc7726ec9e60f4efcfd5045de94e787cd22d873eb5d4e1dbd47da0 xorg-server-1.19.99.903.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.903.tar.gz.sig - ajax 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
[ANNOUNCE] xkbcomp 1.4.1
This release adds the path of the xkbcomp executable to the pkgconfig data, allowing the X server to find the right binary regardless of where its (the X servers) $prefix is pointed. Without this the X server will guess that xkbcomp is configured for the same prefix; since the default prefix is /usr/local, and your distribution certainly did not install xkbcomp there, 'make check' and 'ninja dist' for the X server build would fail because Xvfb would not start. xkbcomp itself has no functional changes in this release. Adam Jackson (2): pkgconfig: Add our bindir to xkbcomp.pc xkbcomp 1.4.1 Peter Hutterer (1): pkgconfig: add the exec_prefix substitution git tag: xkbcomp-1.4.1 https://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.4.1.tar.bz2 MD5: 07df9790d30f9a369d20a418af784de0 xkbcomp-1.4.1.tar.bz2 SHA1: e7585cdb357b9d20c8f3c8a9d06f7e897934a772 xkbcomp-1.4.1.tar.bz2 SHA256: 748dc4cf58ac95684106bd9cf163ac6ab7de9a236faec02a6f4d4006d63a5736 xkbcomp-1.4.1.tar.bz2 SHA512: 443397e112f67e2ebc5150ec0dbf0f4a072ea39585d964d2c7cbd0569b7e0ce7d8bed0bc2c2d886343fdb060c941e65b42aac16adf189c66e90849029e278f23 xkbcomp-1.4.1.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.4.1.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.4.1.tar.gz MD5: 86af4a1fd5b5fabde3a8335dc9474f61 xkbcomp-1.4.1.tar.gz SHA1: 73dd41bd0ddf28b2690ad68d347f28e01d19dcc5 xkbcomp-1.4.1.tar.gz SHA256: 9cdae907b6e34f1f325f6311020126157037925877f323a880e0c9ecab9628f6 xkbcomp-1.4.1.tar.gz SHA512: def786c74ad7f6c5630df6a1dcc0780f5b6271d866818889b7d9869b35fc83c852c8fb9dc9a53e003906936b697a496722dd49fe3e8960fb95ad5262e8c01cff xkbcomp-1.4.1.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/app/xkbcomp-1.4.1.tar.gz.sig - ajax ___ 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
[ANNOUNCE] xorgproto 2018.4
This release updates the specifications and protocol headers for DRI3 and Present to 1.2, and fixes several spelling and grammar errors in the specification texts. Adam Jackson (1): xorgproto 2018.4 Giuseppe Bilotta (1): Spelling and grammar fixes Louis-Francis Ratté-Boulianne (2): dri3: Add modifier/multi-plane requests, bump to v1.2 presentproto: PresentCompleteModeSuboptimalCopy flag git tag: xorgproto-2018.4 https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2018.4.tar.bz2 MD5: 81557ca47ee66a4e54590fcdadd28114 xorgproto-2018.4.tar.bz2 SHA1: 2e4a3db312e1ce81e15515dfcac52ba0aa5a920c xorgproto-2018.4.tar.bz2 SHA256: fee885e0512899ea5280c593fdb2735beb1693ad170c22ebcc844470eec415a0 xorgproto-2018.4.tar.bz2 SHA512: 2db682d10280ca58cdc04d8eb9fef30c111d4cd379de9fec86cff317865b859a576de5426447be9231d24be9762cc1d684c57383a99ad499398e8b7d62b1c03c xorgproto-2018.4.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2018.4.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2018.4.tar.gz MD5: 2763268f5bc742e337415bfedf06b845 xorgproto-2018.4.tar.gz SHA1: a0e2d39316a99266fdbbf8020fe425b6da91409c xorgproto-2018.4.tar.gz SHA256: 8e48d851efea0e951bcb6cf0d537f84ba3803de95e488bd039fe59fc75ec8f7d xorgproto-2018.4.tar.gz SHA512: f79a47fc3de04d7258769869c11e99eff7fa4a4b5925cf60f9f7579f946d7d0e737224e9a54d18e439a3586126e66e0764c0f09ed50987c781955b9b9a1e0362 xorgproto-2018.4.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/proto/xorgproto-2018.4.tar.gz.sig - ajax ___ 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
