Re: Hitting X limit in launching maximum number of vkcube instances
I would start by figuring out exactly why accept() is failing. You could use strace for this, or a patch like: https://gitlab.freedesktop.org/ajax/libxtrans/-/commit/0cf78fc5b4156f0053a6a332f97b4652ed54cb6a Note that to make that patch work you need to patch libxtrans and then rebuild xserver against the result, xtrans is a header-only library. - ajax On Tue, May 16, 2023 at 7:21 PM Anuj Phogat wrote: > On Sat, May 6, 2023 at 9:04 AM Alan Coopersmith > wrote: > > > > On 5/5/23 16:07, Anuj Phogat wrote: > > > Thanks for the quick response Adam. I've seen this behavior across > multiple > > > graphics applications > > > and graphics drivers. This is an extreme use case I'm trying out. So, > there's a > > > possibility of this use > > > case not being handled correctly by any of the applications or > graphics drivers. > > > But I also see some basic X functionality, like closing the window > using the "x" > > > button, not working > > > properly with windows opened past the 256 limit. This happens with a > modified > > > limit of 512. I had to > > > use xkill to close those windows. Any thoughts about this? > > > > Closing the window with the "x" button is a function of the window > manager. > > Does the window manager you are using assume the number of X clients is > > limited to 256? That xkill works suggests the X server is handling it > > correctly. > Alan, I took the window manager out of the equation by running multiple > instances of vkcube with Xorg without running any window manager. > Xorg.0.log file does show a log about set max clients through a .conf file: > (**) Option "MaxClients" "512" > > But, I start seeing below error messages at the end of the log file once > the number of vkcube instances go past 256: > "_XSERVTransSocketUNIXAccept: accept() failed" > > Seems like the modified max clients limit of 512 is not getting configured > correctly in X. > > What can I do to fix / debug this error ? > > > > > > -- > > -Alan Coopersmith- alan.coopersm...@oracle.com > > Oracle Solaris Engineering - https://blogs.oracle.com/solaris > > > >
Re: Hitting X limit in launching maximum number of vkcube instances
No, just MAXCLIENTS. Probably vkcube (or the driver it's using) should fail more robustly when it can't connect to the display, instead of letting you render without presenting though. On Fri, May 5, 2023 at 5:28 PM Anuj Phogat wrote: > Hi All, > > I've been trying to run the maximum number of instances of vkcube (Vulkan > application) > in Ubuntu 22.04. I'm hitting one of these X errors when I get past ~256 > instances: > - "Maximum number of clients reached" > - "_XSERVTransSocketUNIXAccept: accept() failed" > > I was able to get past these errors by adding below code in xorg conf file > passed to Xorg > using '-config' option: > Section "ServerFlags" > Option "MaxClients" "512" > EndSection > > Now I'm not seeing X errors about the limit but X windows past the 256 > limit don't render > anything. Do I need to adjust any other limits (other than MAXCLIENTS) to > make instances > past 256 limit render as expected ? I would appreciate any pointers to > help me debug and > resolve this issue. > > Adding Adam and Olivier in Cc as I noticed a few old patches from them > around changing > MAXCLIENTS. > > Thanks > Anuj >
Re: Fwd: XInitThreads in library constructor breaks Motif!
I missed that! My apologies. I've merged the reentrancy patch, we should probably push out another release shortly. - ajax On Tue, Nov 1, 2022 at 8:16 PM Po Lu wrote: > > > On November 2, 2022 1:25:06 AM GMT+08:00, Adam Jackson > wrote: > >On Mon, Oct 31, 2022 at 8:46 PM Po Lu wrote: > > >Again, I proposed a workaround that preserves the thread-safety guarantee > I > >need, and wrote the patch implementing it. Sure would be nice if someone > >tested it. > > I did say it works for the programs that broke for me. > >
Fwd: XInitThreads in library constructor breaks Motif!
On Mon, Oct 31, 2022 at 8:46 PM Po Lu wrote: > Adam Jackson writes: > > > Because XInitThreads only works if it is called before XOpenDisplay. > > So why not fix that? > > I think the simple fix would be to call _XInitDisplayLock in > XGetXCBConnection. > That wouldn't be sufficient, off the top of my head there's library-global state that gets set up in XInitThreads too and none of the display-level locking will work without it. Again, I proposed a workaround that preserves the thread-safety guarantee I need, and wrote the patch implementing it. Sure would be nice if someone tested it. - ajax
Fwd: XInitThreads in library constructor breaks Motif!
Bah, meant to reply all here. - ajax -- Forwarded message - From: Adam Jackson Date: Mon, Oct 31, 2022 at 12:29 PM Subject: Re: XInitThreads in library constructor breaks Motif! To: Po Lu On Sun, Oct 30, 2022 at 8:10 PM Po Lu wrote: > > Or most people are on Xlib 1.7.x. Anyway, the documentation for X*IfEvent > says it is okay to call functions that take the display lock inside the > predicate given that it does not change the event queue. I have written > such software, and clearly the Open Group has too, along with XFCE, etc. > The documentation absolutely does not say that. The manual page says "Your predicate procedure must decide if the event is useful without calling any Xlib functions". Taking the display lock is an xlib function. It also clearly _calls out_ a case where behavior will _definitely_ be undefined, but the "do not re-enter xlib" restriction is not limited to "do not use xlib to touch the event queue". Besides, how to move it forward? If it works, wouldn't the obvious solution > be to install the change? If all that is needed is for someone to try it > out, I'd be happy to do it, but I'm pretty sure the better solution is just > to remove the call to XInitThreads in the first place. > No. xlib needs to be thread safe in order for other libraries and apps to use xcb reliably. The socket handoff mechanism between xcb and xlib _cannot work safely_ unless the xlib display is thread safe. It will only be thread-safe if XInitThreads was called before XOpenDisplay. The xcb-using component cannot possibly enforce that because the xcb connection is created by xlib, so (for example) libGL would be left with no other option than to refuse to work on non-thread-safe displays. - ajax
Re: XInitThreads in library constructor breaks Motif!
On Mon, Oct 31, 2022 at 8:18 AM Po Lu wrote: If there is really a big problem with clients using XCB, then why not > call XInitThreads in XGetXCBConnection instead? > Because XInitThreads only works if it is called before XOpenDisplay. - ajax
Re: XShmCreatePixmap() as copy dest for XCopyArea()
On Tue, 2020-07-07 at 13:13 -0700, x...@pengaru.com wrote:
> Hello list,
>
> I'm trying to use XShmCreatePixmap() in combination with XCopyArea()
> to achieve something resembling an XShmGetSubImage() for copying
> damaged areas piecemeal out of the root window into a shmseg for a
> screencap tool.
MIT-SHM pixmap support is optional, and often not supported because for
most modern X drivers it's a pessimization. I think there happens to be
a bug in glamor where we claim to support shm pixmaps but don't
actually implement it correctly; does your test case work if you
disable acceleration in xorg.conf?
> It seems like no matter what I do, the XCopyArea() never actually
> writes to the shmseg. If instead I use XShmGetImage() with the same
> source drawable (root) and an XShmImage created from the very same
> shminfo as the XShmPixmap, my shmseg gets written to just fine - but
> it fills the entire XShmImage on every update which I'd like to
> avoid.
XShmGetImage is an awkward API, yeah. The width and height of the image
to download are derived from the XImage, not the drawable; if you
create a shm segment exactly as large as the region you want to copy
it'll do what you want. See the source (sigh) for more details:
https://gitlab.freedesktop.org/xorg/lib/libxext/-/blob/master/src/XShm.c#L373
Strictly speaking, you can just munge image->{width,height} before
sending the request instead of creating a new one, you'll just have to
compensate for that when you read the pixels back out of it.
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver v2] xfree86: Refine drm modes on continuous freq panel
On Tue, 2020-04-14 at 17:28 +0800, Aaron Ma wrote: > EDID1.4 replaced GTF Bit with Continuous or Non-Continuous Frequency Display. There's a lot that's weird about this patch but: > diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c > b/hw/xfree86/drivers/modesetting/drmmode_display.c > index 8e6b697c4..031e5efea 100644 > --- a/hw/xfree86/drivers/modesetting/drmmode_display.c > +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c > @@ -2459,7 +2459,7 @@ drmmode_output_add_gtf_modes(xf86OutputPtr output, > DisplayModePtr Modes) > int max_x = 0, max_y = 0; > float max_vrefresh = 0.0; > > -if (mon && GTF_SUPPORTED(mon->features.msc)) > +if (mon && gtf_supported(output->scrn->scrnIndex, mon)) > return Modes; > > if (!has_panel_fitter(output)) This, to me, is the weirdest bit. If the monitor does support GTF modes, then don't add them? I think you might be able to replace this whole patch by changing just this one line thus: -if (mon && GTF_SUPPORTED(mon->features.msc)) +if (mon && !GTF_SUPPORTED(mon->features.msc)) - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > > pre-merge CI. > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > I wouldn't mind manually triggering pipelines, but unless there is > some trick I'm not realizing, it is super cumbersome. Ie. you have to > click first the container jobs.. then wait.. then the build jobs.. > then wait some more.. and then finally the actual runners. That would > be a real step back in terms of usefulness of CI.. one might call it a > regression :-( I think that's mostly a complaint about the conditionals we've written so far, tbh. As I commented on the bug, when I clicked the container job (which the rules happen to have evaluated to being "manual"), every job (recursively) downstream of it got enqueued, which isn't what you're describing. So I think if you can describe the UX you'd like we can write rules to make that reality. But I don't really know which jobs are most expensive in terms of bandwidth, or storage, or CPUs, and even if I knew those I don't know how to map those to currency. So I'm not sure if the UI we'd like would minimize the cost the way we'd like. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
RFC: Minimum meson version for xserver 20
Does anyone have strong opinions on this? I would really like to bump to at least 0.49 for the position-independent executable support. If not that, 0.47 gives us 'feature' support for build options, which addresses the "should we enable this by default or not" question in a consistent way. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On Tue, 2020-03-17 at 10:12 -0700, Jacob Lifshay wrote: > One related issue with explicit sync using sync_file is that combined > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the > rendering in userspace (like llvmpipe but for Vulkan and with extra > instructions for GPU tasks) but need to synchronize with other > drivers/processes is that there should be some way to create an > explicit fence/semaphore from userspace and later signal it. This > seems to conflict with the requirement for a sync_file to complete in > finite time, since the user process could be stopped or killed. DRI3 (okay, libxshmfence specifically) uses futexes for this. Would that work for you? IIRC the semantics there are that if the process dies the futex is treated as triggered, which seems like the only sensible thing to do. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
On Wed, 2020-03-11 at 12:31 -0500, Jason Ekstrand wrote: > - X11: With present, it has these "explicit" fence objects but > they're always a shmfence which lets the X server and client do a > userspace CPU-side hand-off without going over the socket (and > round-tripping through the kernel). However, the only thing that > fence does is order the OpenGL API calls in the client and server and > the real synchronization is still implicit. I'm pretty sure "the only thing that fence does" is an implementation detail. PresentPixmap blocks until the wait-fence signals, but when and how it signals are properties of the fence itself. You could have drm give the client back a fence fd, pass that to xserver to create a fence object, and name that in the PresentPixmap request, and then drm can do whatever it wants to signal the fence. > From my perspective, as a Vulkan driver developer, I have to deal with > the fact that Vulkan is an explicit sync API but Wayland and X11 > aren't. I'm quite sure we can give you an explicit-sync X11 API. I think you may already have one. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Composite redraw speedup?
On Sat, 2020-02-08 at 15:46 +0100, Egil Möller wrote:
> Hi!
>
> I have for a time now been working on a new composing window manager
> to try
> out a few UX ideas (https://redhog.github.io/InfiniteGlass videos:
> https://www.youtube.com/watch?v=vbt7qtwiLiM
> https://www.youtube.com/watch?v=E8f2KwgvxK4).
>
> However, I'm having a performance problem in my redraw loop: When a
> lot is going on, e.g. during continuous stream of mouse events and/or
> PropertyNotify events + property gets, DamageNotify events for
> windows are often queued up and e.g. animations or video appear
> choppy.
So this bit of the main loop jumps out at me:
while (XPending(display)) {
XNextEvent(display, );
mainloop_event_handle();
XSync(display, False);
}
https://github.com/redhog/InfiniteGlass/blob/master/glass-renderer/mainloop.c#L99
This isn't doing yourself any favors. XSync is a synchronous round-trip
to the server, and on my laptop you get about 80,000 of those a second.
You're doing one of these for every event, and you really shouldn't
need to. What happens if you remove just that call to XSync?
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH 2/2] Add official support for SiS[M]662[MX] integrated graphics
On Wed, 2019-12-25 at 12:52 -0600, Kevin Brace wrote: > From: Kevin Brace > > Signed-off-by: Kevin Brace What's the provenance of these changes? I've seen some hacked packages for additional SiS device support but never got around to merging them all up, would be good to know where this came from. > -#define IS_SIS661741760761 (IS_SIS661 || IS_SIS741 || IS_SIS760 || > IS_SIS761) > +#define IS_SIS661662741760761 (IS_SIS661 || IS_SIS662 || IS_SIS741 || > IS_SIS760 || IS_SIS761) > #define IS_SIS650740((SiS_Pr->ChipType >= SIS_650) && > (SiS_Pr->ChipType < SIS_330)) > #define IS_SIS550650740 (IS_SIS550 || IS_SIS650740) > -#define IS_SIS650740661741760761(IS_SIS650 || IS_SIS740 || > IS_SIS661741760761) > -#define IS_SIS550650740661741760761 (IS_SIS550 || IS_SIS650740661741760761) > +#define IS_SIS650740661662741760761 (IS_SIS650 || IS_SIS740 || > IS_SIS661662741760761) > +#define IS_SIS550650740661662741760761 (IS_SIS550 || > IS_SIS650740661662741760761) Ew. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Flush buffer in time for global (un)lock xserver operation
On Wed, 2019-12-04 at 18:24 +0800, cheng...@emindsoft.com.cn wrote: > From: Chen Gang > > The global (un)lock xserver operations will have effect to the whole > system, and all the other gui apps have to be blocked, so the operations > should not be buffered, or may cause sync issue, e.g. reboot machine. Enh. I can maybe see the point of this for XUngrabServer, but I think doing this for XGrabServer may actually make interactivity worse. With the code as it is currently, the GrabServer request will be buffered inside the client until something happens to flush it out (presumably something like QueryTree or GetImage that provokes a reply), and while it stays buffered other clients may still interact with the server. With this change you'll immediately write the request to the server, and you might lose your scheduler timeslice as a result, in which case not only will the grabbing client need to wait to reschedule but every other client will need to wait in line behind the grabbing client. Do you have a scenario in mind that this helps with? Does doing _XFlush only for XUngrabServer work just as well? - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xorgproto header installation conflicts
On Sun, 2019-11-24 at 23:04 +0100, Thomas Klausner wrote: > Thanks for the hint! > > Is anything else from this list effectively dead? Yes: > libXevie Not implemented in xserver since 1.6 (late 2008), rarely used by any clients. > libXxf86misc Likewise. This is the client-side part of xf86miscproto. However there were many clients that linked against it (because it was rather useful in xfree86 days), so you may want to keep it around for ABI reasons. In Fedora we've just copied the headers into the source package so we can keep building the library without needing --enable-legacy in xorgproto. Refer to the magic tricks invoked here: https://src.fedoraproject.org/rpms/libXxf86misc/blob/master/f/libXxf86misc.spec#_35 But as you noted above you already removed it, which, good. > libxkbui Long ago some xkb utilities would use this to draw images of keyboard layouts, which, enh, marginal value I guess. It looks like Fedora didn't even bother to package this post-modularization (2006ish). I have vague memories that some version of gnome's control panel would try to use this, but apparently it's been a very long time since that was true. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xorgproto header installation conflicts
On Fri, 2019-11-15 at 11:08 +0100, Thomas Klausner wrote: > Hi! > > I've updated pkgsrc to use xorgproto 2019.2, still installing the > legacy headers with --enable-legacy, and we had to fix a couple > conflicts: > > * XKBgeom.h is provided by libX11 1.6.9 > * vlcXvMC.h is provided by libXvMC 1.0.12 > > I guess as long as they are installed by the other libraries, they > should not be installed by xorgproto. Or should they be removed from > the other libraries? If you're building xorgproto with --enable-legacy it's up to you to handle the packaging conflict, presumably remove them manually in either xorgproto xor in the libraries. If you wanted to a patch for the libraries to detect which kind of xorgproto you had and handle it gracefully there instead, point me at the merge request. ;) - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xserver release process
On Tue, 2019-10-08 at 22:19 +0200, Hans de Goede wrote: > Hi, > > On 08-10-2019 18:28, Adam Jackson wrote: > > > In short, releases need to happen, and we have CI, so let's just pop a > > release out on scheduled dates assuming CI passes. > > Given that the Xorg xserver has a lot of hw interaction, we are > never going to catch everything with CI, so this seems a bit > over-simplified. I mean, yes, it's over-simplified. The alternative is not doing releases, apparently. The idea here is that we keep adding more coverage to CI, and we fake hardware coverage if we need to by writing more tooling around vkms and friends. This may mean that any given point-zero release is less stable than we might like, but that's not exactly new, and having cheap-and-frequent stable releases should help mitigate that. > I think it would be good to have 2 things: > > 1. A way to track potential blocker bugs. Note I'm not advocating some > process heavy approach here. The blocker bugs can just be gitlab issues > with a special tag I guess. The idea is that the release-coordinator > at least can get a list of known issues and then decide if those are bad > enough to delay a release or not. Milestones: https://gitlab.freedesktop.org/xorg/xserver/-/milestones - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
xserver release process
I gave a brief lightning talk about this at XDC Montreal [1], and nobody seemed to object, but here's a recap for those who weren't present or have other ideas or preferences. In short, releases need to happen, and we have CI, so let's just pop a release out on scheduled dates assuming CI passes. Six months seems to be a pretty reasonable cadence for xserver major releases as new feature development has tailed off a bit. Likewise for stable branches, if there's been changes to the branch and it's been (say) two weeks since the last release on that branch, and CI passes, automatically do a new release. I intend to make this _entirely_ automatic, with a robot doing the actual commits and release uploads. Also, let's adopt the Mesa "last two digits of the year" version scheme, it makes it easy to see how old your software is at a glance. We'll need to be slightly careful about this to ensure we don't make the (protocol) release number go crazy, so the scheme looks something like this (underscores for clarity): - xserver 1.20.5 → 1_20_05_000 - xserver 19.0.0 → 1_20_19_000 - xserver 19.0.1 → 1_20_19_001 - xserver 19.1.0 → 1_20_19_100 - xserver 20.0.0 → 1_20_20_000 Suggestions and comments are welcome, with the understanding that anything much more complicated or too different than this implies that you're volunteering to do all the work. (Not that that's a problem, just letting you know what you're signing up for.) [1] Starting approximately here: https://youtu.be/JIry8jpbPUY?t=32790 - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Fonts: Pango Drops Bitmap Support.
On Mon, 2019-07-29 at 14:36 +0100, Ralph Corderoy wrote: > Is there any chance X.org can ship their super collection of fonts as > OpenType bitmaps as well? I understand it's a mechanical conversion. > That would allow distro packagers to make them readily available to > users alongside the existing BDFs, etc., so they can continue to use > their decade-old favourites. Do you have a link to a recipe for such mechanical conversion? I think we would still preserve the BDF as the "source" format but I'd certainly be happy to install them as something other than PCF. (For that matter I might like to ship my OS without PCF support in the renderer at all.) - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: X.Org modules which could use some help to release
On Mon, 2019-07-22 at 12:53 -0400, Felix Miata wrote: > No joy: > (EE) TSENG(0): No valid Framebuffer address in PCI config space; > > Does this mean the ET6100 needs manual configuration of PCI Bus ID? Other? I think it means the driver is broken, now. Repairable, but. Specifically: > [72.334] (WW) Falling back to old probe method for tseng If we ever see this for a PCI device, where the driver subsequently binds and tries to initialize, then something has probably gone wrong. In this case it's that the tseng driver lacks a pci-specific probe method (the PciProbe slot in DriverRec), and the "old" probe method seems not to find the corresponding PCI device descriptor. So by the time we hit here: https://gitlab.freedesktop.org/xorg/driver/xf86-video-tseng/blob/master/src/tseng_driver.c#L883 PCI_REGION_BASE() returns NULL here since the device descriptor is empty, and the driver throws its hands up in despair. But the real descriptor _does_ correctly describe the video memory BAR: [72.041] (--) PCI:*(0:0:10:0) 100c:3208:: rev 112, Mem @ 0xe800/16777216, I/O @ 0xd000/256, BIOS @ 0x/16777216 There are other drivers that also only have a legacy probe method that I believe have been seen to work since the pciaccess conversion, so I'm sure this is fixable. But apparently I dropped those drivers from Fedora about eight years ago, so I'm unlikely to find time to fix them. Should be an easy project for anyone who has such hardware to test with though. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: X.Org modules which could use some help to release
On Sun, 2019-07-21 at 10:08 +0100, Jon Turney wrote: > On 16/07/2019 20:07, Adam Jackson wrote: > > On Mon, 2019-07-15 at 14:31 -0700, Alan Coopersmith wrote: > > > On 7/15/19 4:02 AM, Thomas Klausner wrote: > > > > > > > libWindowsWM > > > > > > This is supposed to only be useful on Cygwin, but a Cygwin package search > > > says they don't ship it, and it hasn't had a release since 2009, so I > > > wonder if anyone uses it, or just keeps building it because no one ever > > > said "stop". > > I think this can be archived, so I'll say "Stop!" :-) I've gone ahead and archived this library. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: X.Org modules which could use some help to release
On Sun, 2019-07-21 at 09:29 -0400, Felix Miata wrote: > Adam Jackson composed on 2019-07-16 15:33 (UTC-0400): > > > On Sun, 2019-07-14 at 18:34 -0700, Alan Coopersmith wrote: > > > > - driver/xf86-video-tseng > > > These are drivers for some fairly ancient PCI devices, both Tseng Labs > > and Ark Logic were out of the graphics chip business by 1999. If > > someone wants to verify that they work with a current release, neat, > > but this is serious necrocomputing territory. > > Does any distro package this? It's the best there ever was for DOS users. I > would > test if I could find an .rpm (Mageia, openSUSE, Fedora) or .deb (Buster, > AntiX) to > install. Fedora did for a while: https://src.fedoraproject.org/rpms/xorg-x11-drv-tseng/tree/f16 - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: X.Org modules which could use some help to release
On Sun, 2019-07-14 at 18:34 -0700, Alan Coopersmith wrote: > - driver/xf86-video-ark > - driver/xf86-video-tseng These are drivers for some fairly ancient PCI devices, both Tseng Labs and Ark Logic were out of the graphics chip business by 1999. If someone wants to verify that they work with a current release, neat, but this is serious necrocomputing territory. > - driver/xf86-video-armsoc Driver for some Mali chipsets, untouched since 2016. I think this niche might be served by the generic modesetting driver at this point. > - driver/xf86-video-impact > - driver/xf86-video-newport 2D-only drivers for a couple of SGI chipsets. Probably more worth preserving than ark or tseng since for the machines in question they're all you're going to get. > - driver/xf86-video-nested (has never had a release?) I think this driver's existence might be a strategic error. > - driver/xf86-video-tga Driver for some DEC Alpha machines; see above about impact/newport. > - driver/xf86-video-xgi This one is probably the most relevant? The XGI Z7/Z9/Z11 found modestly wide deployment in x86 servers for a while. Ideally someone would port this to KMS so it can live alongside the other server chips like mgag200 and aspeed, but the UMS driver probably works as well as it ever did and might as well get a release. > - driver/xf86-video-xgixp A driver for the XGI Volari 8300, which was a DX9-ish part from the ex- Trident group at XGI. If you happen to have this ~15 year old piece of unobtanium, by all means let us know if the driver still works. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: X.Org modules which could use some help to release
On Mon, 2019-07-15 at 14:31 -0700, Alan Coopersmith wrote: > On 7/15/19 4:02 AM, Thomas Klausner wrote: > > > libWindowsWM > > This is supposed to only be useful on Cygwin, but a Cygwin package search > says they don't ship it, and it hasn't had a release since 2009, so I > wonder if anyone uses it, or just keeps building it because no one ever > said "stop". In principle it would be useful for any window manager that happens to be driving a server with that extension (likely only on win32), but if you're running your wm on a different machine/os from your win32 display you are doing something kinda weird. In practice, I had trouble finding _any_ window manager that used this extension, and the server-side code has been deleted in master: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/178 - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: libXt release
On Mon, 2019-06-17 at 10:08 -0400, Matt Turner wrote: > Thanks. Are you familiar with the Xorg release scripts [0]? There's a > wiki page at [1] that has instructions. > > If for any reason you have trouble making the release or uploading the > tarball, let me know and I'll be happy to handle it. I believe uploading the release tarball is one of the few steps for which one still needs an ssh account to fd.o. We should probably figure out how we want to handle that going forward, as we (fd.o) would like to reduce or eliminate shell service in the future. I'm open to suggestions here, how are other gitlab projects handling this now? - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Cannot submit merge request for xf86-video-intel
On Sat, 2019-05-11 at 21:17 +0200, Maarten Maathuis wrote: > Given that the xf86-video-intel repo hasn't been been set up for PRs > it seems (as opposed to lets say the xserver). > I see in https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel > the following people having made the most recent changes: > > Ville Syrjälä: ville.syrj...@linux.intel.com (found via a commit > message with sign-off tag) > Eric Anholt: e...@anholt.net > Adam Jackson: a...@nwnk.net I don't have an active development interest in the intel driver, I just ship it. My most recent patch was just because I couldn't get it to build on 32-bit in Fedora, and I wasn't the one that merged it. In general I try not to force-push patches to drivers that have active maintenance. Which intel does have, despite the lack of releases; people pretty much just use git snapshots and that seems to be sufficient. The intel driver hasn't migrated to gitlab yet, Intel have internal processes that revolve around bugzilla and the mailing list still AFAIK. intel-gfx@ was the right place to send the patch. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xorg-xserver/Xext/shm.c - missing swapped case?
On Mon, 2019-05-06 at 23:40 +0200, Ulrich Sibiller wrote: > On Mon, May 6, 2019 at 6:28 PM Alan Coopersmith > wrote: > > On 5/6/19 9:20 AM, Ulrich Sibiller wrote: > > > Since that code is really old (the PANORAMIX stuff came in with > > > XFree86 4.3.0.1 in November 2003) I am wondering if this really a bug > > > or if am missing something crucial here? > > > > I don't think X has ever truly supported a platform on which clients > > of different endianess can share memory - shared memory is typically > > local only, while endian swapping is typically remote only. > > I agree. So the current situation is that the code is > a) incomplete > b) never used > > IMHO consequently all the swapping code should be dropped from shm.c. > Swapped requests (wherever they come from) should simply return an > error then. Swapped shm requests have been fixed by explicit request before: https://bugs.freedesktop.org/show_bug.cgi?id=4730 But yes, the swapped code is wrong for the xinerama case. The simplest fix is to replace the return statements in the SProc stubs with: return ProcShmDispatch(client); which will forward the (now-swapped) request on to the xinerama-aware dispatch path. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
xserver release process and gitlab
I was asked off-list what tasks are involved in releasing a new X server, since eventually people are probably going to want one. And that's a good question! The unfortunate answer is that the process has been informal and has varied over time. We have often used tracking bugs in bugzilla to define the set of remaining issues to address within a release, but we're not using bugzilla anymore. So I think it's probably a good idea to start with the processes available to us in gitlab. From what I can tell, "milestones" are the best fit for this. I've created a starter milestone to track 1.21: https://gitlab.freedesktop.org/xorg/xserver/milestones/1 Anyone with "developer" access or higher to the xserver project should be able to edit this milestone, but the release manager (whoever that ends up being) should have final editorial control. If you think an issue should be added to this milestone, comment on the issue or find a developer who can nominate it for you. I'll take a pass through the issue list in the next few days and nominate some likely bugs. In general, candidate issues for a major release include crash fixes, regressions, and major feature work. The release manager should ensure all such issues have assignees, and check in on their progress regularly. Establishing a release schedule should itself be one of the issues resolved for a given release (since you can't comment on a milestone proper, only on issues attached to it). So let's do that here: https://gitlab.freedesktop.org/xorg/xserver/issues/688 We don't currently have formal acceptance criteria for a release, though an obvious minimum would be to have 'ninja -C build test' pass on all major platforms in CI. We should document this testing process, as well as define criteria for adding additional acceptance criteria. Vaguely related to all this is that we badly need to get our documentation moved from the old wiki to gitlab. There's an open issue for this, but it's a few months inactive: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/80 If any of this sounds too crazy, or if there are other things we need to address, please let us know so we can address them. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Radeonhd repo not migrated to gitlab.
On Wed, 2019-03-06 at 17:04 +0100, Luc Verhaegen wrote: > Is there a reason why, of _all_ drivers listed in > > https://cgit.freedesktop.org/xorg/driver > > the Radeonhd repository at > > https://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/ > > has not been mirrored? Pretty sure I came up with the list of modules to migrate from the set I happened to have cloned locally, but it's been months. I've added a note to the migration ticket: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40 - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Port of X11 to Windows 32-bit
On Tue, 2019-02-26 at 08:20 -0500, James Larrowe wrote: > I'm working on nonintrusively patching Xlib and the X server to work > natively on Windows 32-bit, and I'm interested in upstreaming the > patches. I have two questions: > 1. Would they be welcome? Almost certainly, although I'm not sure how much more "native" you're planning to get. The mingw build already talks directly to win32 APIs. Can you elaborate on what you're trying to do here? Note that we're not likely to support new build systems, unless that build system is named meson. > 2. What is the coding style/indentation style that X uses? "Wildly inconsistent". If you're modifying existing code it's usually best to follow whatever the local style is. For new code we typically prefer K with 4 space indents. Running the x-indent.sh script should get you pretty close: https://gitlab.freedesktop.org/xorg/util/modular/blob/master/x-indent.sh - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xorg-docs] The Katamari is dead! Long live the Katamari!
On Sun, 2019-02-24 at 12:58 -0800, Alan Coopersmith wrote: > I come not to praise the Katamari, but to bury it... > > Signed-off-by: Alan Coopersmith Reviewed-by: Adam Jackson - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
xserver 1.20.4 maintenance release
Hey, I need one of these, so I've got a merge request posted with some bugfixes from master backported: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/125 If there's anything in there you hate, or anything not in there that should be, give a shout. I'd like to push this out sometime this week. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86EnableIO & ExtendedEnabled vs. the input thread
On Fri, 2019-02-15 at 17:00 -0800, Alan Coopersmith wrote: > but I'm guessing instead we should have some sort of callback or ddx-specific > initialization called from inputthread, that happens to be an empty stub > everywhere but the xf86 ddx for Solaris. Yeah, that sounds better. Bool ddxInputThreadInit(void) perhaps. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: How do I compile and package the X Server code?
On Tue, 2019-02-12 at 17:22 +0100, Kevin Brace wrote: > I am able to compile X Server, although I do not know at this point > how to install it to my preferred location (I will like to install it > to /opt for testing purposes). https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Default-Prefix.html You will probably also want to override PKG_CONFIG_PATH in the environment when building drivers against that server. Refer to the pkgconfig documentation for details, but it's probably something like: $ export PKG_CONFIG_PATH=/opt/xorg/share/pkgconfig:/opt/xorg/lib64/pkgconfig:$PKG_CONFIG_PATH That said... in my experience, one of the pleasant features of using a distribution is that you can reinstall packages. If I ever really do want to test a new buld of Xorg (the only server where the install path really matters) I just clobber the existing one, and when I'm done, dnf reinstall xorg-x11-server-*. > How do I install it to my preferred location and run the compiled > version rather than the existing version? If you're invoking the X server by hand, just do: # /opt/xorg/bin/Xorg Convincing your desktop environment's display manager to invoke that one instead of the one in /usr/bin depends on the particular display manager. (Not wanting to remember how to do this is part of the reason I don't use prefixes...) - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload
On Fri, 2019-02-08 at 10:19 -0800, Andy Ritger wrote:
> (1) If configured for PRIME GPU offloading (environment variable or
> application profile), client-side libglvnd could load the possible
> libGLX_${vendor}.so libraries it finds, and call into each to
> find which vendor (and possibly which GPU) matches the specified
> string. Once a vendor is selected, the vendor library could optionally
> tell the X server which GLX vendor to use server-side for this
> client connection.
I'm not a huge fan of the "dlopen everything" approach, if it can be
avoided. I think I'd rather have a new enum for GLXQueryServerString
that elaborates on GLX_VENDOR_NAMES_EXT (perhaps GLX_VENDOR_MAP_EXT),
with the returned string a space-delimited list of :.
libGL could accept either a profile or a vendor name in the environment
variable, and the profile can be either semantic like
performance/battery, or a hardware selector, or whatever else.
This would probably be a layered extension, call it GLX_EXT_libglvnd2,
which you'd check for in the (already per-screen) server extension
string before trying to actually use.
> At the other extreme, the server could do nearly all the work of
> generating the possible __GLX_VENDOR_LIBRARY_NAME strings (with the
> practical downside of each server-side GLX vendor needing to enumerate
> the GPUs it can drive, in order to generate the hardware-specific
> identifiers).
I don't think this downside is much of a burden? If you're registering
a provider other than Xorg's you're already doing it from the DDX
driver (I think? Are y'all doing that from your libglx instead?), and
when that initializes it already knows which device it's driving.
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Unlocking xf86-video-ark and xf86-video-apm GitLab projects
On Tue, 2019-02-05 at 02:58 +0100, Kevin Brace wrote: > Hi, > > I know the devices in question were abandoned in late 1990s, but can > someone take those two DDXs out of archived status over at GitLab? > I do have 4 patches I will like to commit into xf86-video-apm [1]. De gustibus non est disputandum. I've unarchived the drivers, go wild. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86EnableIO & ExtendedEnabled vs. the input thread
On Wed, 2019-01-23 at 14:22 -0800, Alan Coopersmith wrote: > I've confirmed with our kernel folks that the syscall we call from > xf86EnableIO() on Solaris has always only set the IOPL for the calling > thread and not other threads. They believe the primary difference between > Linux & Solaris is that when a new thread is spawned, it inherits the IOPL > on Linux, but on Solaris we reset the IOPL for the new thread instead of > inheriting it. Makes sense to me. > While we could update this in the kernel, that won't solve the problem for > people on older kernels, or one of the OpenSolaris off-shoots (and wearing > my security hat, I actually prefer the least-privilege method of not having > all new threads inherit the iopl from the main thread). Agreed. > But I have to ask if anyone remembers why we keep track of this flag in > userspace at all - it's not just Solaris, but it seems to have been > cargo-culted to most platforms: > > hw/xfree86/os-support/bsd/arm_video.c > hw/xfree86/os-support/bsd/i386_video.c > hw/xfree86/os-support/linux/lnx_video.c > hw/xfree86/os-support/solaris/sun_vid.c > > Is there any reason we just don't drop ExtendedEnabled altogether and > just always pass the calls through to the kernel? That'd leave us > still needing to call xf86EnableIO() in the input thread on Solaris, > unlike Linux, but that's more sensible than forcing a DisableIO() > first just to reset the ExtendedEnabled state. I can't think of a good reason to track ExtendedEnabled, no. All of the implementations look like they're idempotent (though I had to read the weird Linux ppc thing twice to be sure). The ExtendedEnabled logic itself seems to predate XFree86 4.0, which is back far enough in the dark ages that I don't think we'd ever find a useful changelog for its motivation. I say nuke it. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xwayland 1/3] xwayland: Separate DamagePtr into separate window data
On Tue, 2019-01-15 at 23:21 +0100, Carlos Garnacho wrote:
> This will be dissociated in future commits to handle the cases
> where windows are being realized before there is a compositor
> handling redirection.
>
> In that case, we still want the DamagePtr to be registered upfront
> on RealizeWindowProc before a corresponding xwl_window might be
> created. Most notably, it cannot be lazily created on
> SetWindowPixmapProc as damage accounting gets broken. The downside
> of this is that we may create no-op DamagePtrs for windows that are
> not redirected eventually.
I don't think this downside ever happens. For rootless mode we only
create the xwl_window for windows that are already RedirectDrawManual,
and the changes you're making to xwl_realize_window are well after that
check.
>
> @@ -552,18 +597,9 @@ xwl_realize_window(WindowPtr window)
>
> wl_surface_set_user_data(xwl_window->surface, xwl_window);
>
> -xwl_window->damage =
> -DamageCreate(damage_report, damage_destroy, DamageReportNonEmpty,
> - FALSE, screen, xwl_window);
> -if (xwl_window->damage == NULL) {
> -ErrorF("Failed creating damage\n");
> -goto err_surf;
> -}
> -
> compRedirectWindow(serverClient, window, CompositeRedirectManual);
>
> -DamageRegister(>drawable, xwl_window->damage);
> -DamageSetReportAfterOp(xwl_window->damage, TRUE);
> +register_damage(window);
register_damage() can fail, you've thrown away the error checking here.
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Xwayland on demand (Re: [PATCH xwayland 3/3] xwayland: Handle the case of windows being realized before redirection)
On Wed, 2019-01-16 at 11:52 +0200, Pekka Paalanen wrote: > What I think we would need is a way to launch Xwayland, but ensure it > does not process the real X11 apps until all the preparations (xrdb, > XWM init, etc.) have finished. What the preparations are exactly, only > the Wayland compositor (the desktop) will know. Who's launching this first X11 app, and why are they unable to defer launching it until the Xwayland is prepared? There's quite a few ways we could add this kind of interlock to setup, I just want to clarify which problem we're solving first. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-video-vmware compilation issue with xserver built with meson
On Sat, 2019-01-12 at 12:18 +, Tuomo Rinne wrote: > The correct fix would be to use #ifdef statements in the xf86-video-vmware > driver correct? I'm happy to send a patch if this is the case. I think that's the best fix. xserver's never going to do #define XSERVER_LIBPCIACCESS 0 so using #ifdef should be portable. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add 24-bit color support to exaGetPixmapFirstPixel
On Mon, 2018-12-17 at 23:54 +0100, Kevin Brace wrote: > The rendering is fine for the login screen as far as I am concerned, > so I would imagine that EXA can theoretically support 24 bpp, but no > one really tried since by the time EXA was developed, every new > graphics had 32 bpp support, and developers "forgot" to support 24 > bpp only graphics cards. exa definitely had intended to support 24bpp at one point. I deleted the code for it in 1.20 though: https://gitlab.freedesktop.org/xorg/xserver/commit/0803918e64262482035f042e5e1f2a571d3dea1b > I do not see any particular harm backporting that one line inside the > still supported X Servers. (1.16 through 1.20) The change would do nothing for 1.20, and I'm not about to do any more pre-1.20 releases. If someone else wants to, be my guest. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add 24-bit color support to exaGetPixmapFirstPixel
On Thu, 2018-12-13 at 22:32 -0600, Kevin Brace wrote: > It appears that people who developed EXA forgot that there used to be > graphics devices that used 24-bits (3 bytes) instead of 32-bits (4 bytes) > in order to display one pixel. The lack of 24-bit color support inside > exaGetPixmapFirstPixel causes SiS 6326 to crash when running Xfce since > SiS 6326 does not support 32-bit color. fb doesn't support 24bpp anymore, so this patch isn't going to do anything useful I don't think. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
X server bugzilla is closed, please use gitlab instead
I've turned off new bug entry in bugzilla for the X server and the modesetting driver. Please use gitlab issues for all new reports: https://gitlab.freedesktop.org/xorg/xserver/issues Existing bugs can still be modified, but will eventually be migrated into gitlab as well. They've not been migrated yet partly because a triage pass for obviously fixed or invalid issues would be a good idea, but also because I'm having authentication issues with the migration script. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Repos to archive?
On Tue, 2018-11-20 at 09:34 -0800, Eric Anholt wrote: > Alan Coopersmith writes: > > > While iterating over all the /xorg/ repos to update their READMEs > > (which I think I've now finished - let me know if you spot one I missed), > > I noticed a few more to consider archiving: > > I agree with your reasoning for all of these. Almost all likewise. I've archived all of these except for libxcwm, it's both the only one with any issues filed (imported from bz) and I think in principle was part of some Xquartz rework that might still be relevant. Thanks for looking into this! - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
What could it mean for a visual to have more than one depth?
I've been looking at cleaning up pixmap format and visual initialization. I'm having some difficulty understanding why the code is currently doing what it's doing. Perhaps someone has an idea. In the initial connection block, a DEPTH is a tuple of a depth and a list of visuals. A VISUALTYPE is a tuple of (visual-id, visual-class, rgb-masks, bits-per-rgb, colormap-entries). Note that a VISUALTYPE does not specify depth. The protocol contains the following enigmatic text: "A given visual type might be listed for more than one depth or for more than one screen." Assuming that "visual type" here means a VISUALTYPE - which seems pretty reasonable - the interpretation for more than one screen makes sense. The visual ID and all its properties happen to be numerically equal on more than one screen, and this is never ambiguous because windows are always created relative to a particular root window. Listing a visual for more than one depth, though, I can't figure out what that could possibly mean. Maybe if you make a depth-16 window on a Visual that can also do depth-24, then PutImage will automatically do the obvious color expansion? (Or the reverse.) But if you have that, what do you put in rgb-masks to make it make sense for both depths? Maybe instead this is for PseudoColor hardware that wants to expose (say) both depth-4 and depth-8, and have the initial 16 colormap entries shared between depth-4 and depth-8 visuals, so that apps only expecting depth 4 can work transparently? More practically, the existing drivers - and every server I've ever seen - only ever have one depth per visual, and applications are by now quite prepared to deal with having tons of visuals thanks to GLX and Composite. Would enforcing a 1:1 map from Visual to Depth be an implementation burden on the server side for any reasonable class of hardware? - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] dix: do not send focus event when grab actually does not change
On Mon, 2018-11-19 at 18:06 +0100, Samuel Thibault wrote: > Hello, > > Ping? Tsk, thought I'd pushed this already. Merged, thanks: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/77 - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xorg-docs 1/4] Update docs for gitlab migration
On Sat, 2018-11-17 at 14:46 -0800, Alan Coopersmith wrote: > diff --git a/general/README.xml b/general/README.xml > index 7446fa0..b7fe484 100644 > --- a/general/README.xml > +++ b/general/README.xml > @@ -243,13 +243,12 @@ page. > > > If you have any new work or enhancements/bug fixes for existing work, > -please send them as git format patches to > -xorg-de...@lists.freedesktop.org or to our > -https://bugs.freedesktop.org/;>bug tracking system > -using the xorg component. This will help ensure that they are included > +please submit them via > +https://gitlab.freedesktop.org/xorg;>the gitlab.freedesktop.org > code management system. > +This will help ensure that they are included > in future releases. More details on patch submission and review > process are available on the > - url="http://www.x.org/wiki/Development/Documentation/SubmittingPatches;> > + url="https://www.x.org/wiki/Development/Documentation/SubmittingPatches;> I've updated this wiki page to talk about gitlab first, and moved the email-based workflow to the end. Series is: Reviewed-by: Adam Jackson - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Patch for glibc 2.25+ in xserver config/udev.c
On Mon, 2018-11-12 at 13:48 -0800, Manoj Gupta wrote: > Is this the right mailing list for this patch? If not, please advise. This is the right list, although we're generally moving to gitlab for patch submission: https://gitlab.freedesktop.org/xorg/xserver/ > diff --git a/config/udev.c b/config/udev.c > index 8c6c4b666..c5edc9932 100644 > --- a/config/udev.c > +++ b/config/udev.c > @@ -38,6 +38,11 @@ > #include "os.h" > #include "globals.h" > #include "systemd-logind.h" > +#include "xorg-config.h" This is incorrect, though an understandable mistake to make. xorg- config.h should ideally only be included from files under hw/xfree86/, outside of that the code is potentially built into multiple servers so it should use dix-config.h instead. This file already includes dix-config.h, so instead we should change include/dix-config.h.in to also have a #undef HAVE_SYS_SYSMACROS_H so that... > +#ifdef HAVE_SYS_SYSMACROS_H > +#include > +#endif ... the above will see the macrod as defined. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] dix/window: Use ConfigureWindow instead of MoveWindow
On Mon, 2018-11-12 at 13:51 +0100, Michal Srb wrote: > The screensaver can regularly move its window to random offsets. It should > use the ConfigureWindow function instead of calling the Screen's MoveWindow > directly. Some MoveWindow implementations, such as compMoveWindow, rely on > Screen's ConfigNotify being called first as it happens in ConfigureWindow. > --- > This fixes abort from assertion failure if compositing is used together with > screensaver configured using "xset s 2 1 s noblank" command. > > The compCopyWindow function would abort because of: > > assert(cw->oldx != COMP_ORIGIN_INVALID); > > Because the cw->oldx is set from compReallocPixmap which is only called > from compConfigNotify. > > Alternatively, if the MoveWindow is supposed to work independently, the > compMoveWindow must be adapted to handle the case when oldx/oldy is > set to COMP_ORIGIN_INVALID. Nah, ConfigNotify is expected before MoveWindow, this patch looks good. Merged, thanks. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: libpciaccess on GNU/Hurd
On Wed, 2018-11-07 at 22:56 +0100, Samuel Thibault wrote: > Adam Jackson, le mer. 07 nov. 2018 15:09:58 -0500, a ecrit: > > Because the kernel is the one thing in a position to enforce access > > exclusion. > > root-owned processes can still use ioperm to get access to io ports and > break that. Maybe on your kernel. Mine doesn't allow ioperm even for root. > > If you try to implement this with a userspace arbiter then > > all you need to do to break it is run an old version of libpciaccess. > > Sure. Except if ioperm is allowed only for the pci arbiter. ... but that's all you need. Call ioperm, if it succeeds you must be the arbiter, so you install the x86 backend. If it fails you use the arbiter backend. There's no reason for pci_system_init()'s caller to care. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: libpciaccess on GNU/Hurd
On Wed, 2018-11-07 at 18:27 +0100, Samuel Thibault wrote: > Adam Jackson, le mer. 07 nov. 2018 12:04:52 -0500, a ecrit: > > On Mon, 2018-11-05 at 22:56 +1100, Damien Zammit wrote: > > > > > I wish to propose an additional api call to libpciaccess. > > > Before I submit a patch, I wish to get some feedback from the devs. > > > > > > In GNU/Hurd currently, applications use the x86 backend from > > > libpciaccess. This poses concurrency issues when multiple applications > > > run at the same time accessing pci. > > > Thus we want to make libpciaccess do operations through an arbiter. > > > The pci arbiter would use libpciaccess to access the x86 methods, but > > > then we wish to make applications use the hurd method on top of that. > > > > What I'd do instead is make a kernel service for this and have the Hurd > > backend call that, > > Why would it _need_ to be a kernel service? Because the kernel is the one thing in a position to enforce access exclusion. If you try to implement this with a userspace arbiter then all you need to do to break it is run an old version of libpciaccess. > > The 'x86' backend is fundamentally broken (as you've noticed) > > How do you see it broken? (considering that the concurrent access issue > is solved by moving it to a central place) 1) PCI configuration space access isn't atomic. You write to 0xCF8, then read/write 0xCFC. Process A writes CF8, process B writes CF8, process A reads/writes to the device process B was trying to access. Note that either of these processes can be device drivers, so a not- even-malicious userspace process can confuse unrelated drivers. We hit this kind of thing in Linux long ago, to the extent that starting X would reprogram your IDE controller and halt further disk access, which is why it moved config space access to sysfs so the kernel could enforce mutual exclusion. I'll assume that the design you're contemplating has a pci arbiter server handling the actual port I/O, and that for normal processes inl/outl would trap and relay the command to the arbiter. If that was all you did that would still not be safe, because the x86 backend still encodes config space access as two port operations, translated into two calls to the server. You would need to make the arbiter cache the last value written (by every client) to CF8 and re-emit it before any access to CFC. 2) No support for multiple PCI domains, because the CF8/CFC access method doesn't have any way to encode a domain. 3) No support for things that aren't x86. Not a concern for Hurd, perhaps, but if that's a thing you ever want maybe solve it portably up front. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] xwayland: use wl_surface_damage_buffer
On Mon, 2018-11-05 at 18:25 +, Simon Ser wrote: > On Monday, November 5, 2018 3:24 PM, Pekka Paalanen > wrote: > > I don't think it's a good idea to break Xwayland completely on > > compositors that don't implement wl_surface version 4 or greater. > > > > It would make sense to bind wl_compositor min(version, 4). > > This is intentional. I think it's reasonable to expect wl_compositor v4, it's > pretty old (3 years old). For instance, compositors not implementing v4 have > no > damage tracking with EGL. > > I think it's worth it to require v4 rather than cluttering the codebase with > version checks. I tend to agree. weston, mutter, and wlroots seem to all support it. wlc doesn't but it's been deprecated. I don't know how to look this up for KDE easily short of installing and running it; if someone could verify that it implements v4 then I'd be happy to see this merged. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: libpciaccess on GNU/Hurd
On Mon, 2018-11-05 at 22:56 +1100, Damien Zammit wrote: > I wish to propose an additional api call to libpciaccess. > Before I submit a patch, I wish to get some feedback from the devs. > > In GNU/Hurd currently, applications use the x86 backend from > libpciaccess. This poses concurrency issues when multiple applications > run at the same time accessing pci. > Thus we want to make libpciaccess do operations through an arbiter. > The pci arbiter would use libpciaccess to access the x86 methods, but > then we wish to make applications use the hurd method on top of that. What I'd do instead is make a kernel service for this and have the Hurd backend call that, because that'd look like what every other sane OS does. The 'x86' backend is fundamentally broken (as you've noticed) and it would be preferable if none of the supported OSes need it anymore. Hurd being one of the last that needs it... If you don't want to fix Hurd's kernel, then wat I'd do instead is create a Hurd backend inside libpciaccess. Change x86_pci_methods to _pci_hidden instead of static, create a hurd_pci_methods vtable that takes whatever arbitration lock you want (some lock file in /tmp or whatever) and then calls through to the x86_pci_methods vtable. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Mod4 + O is blocked from applications
On Mon, 2018-11-05 at 13:41 +0200, hoshi wrote: > Hi, I have tested on some user applications (Emacs, gedit,...) and > found that Mod4+O, Mod4+P is not sent to the applications. Instead, > they show the cursor (if it's hidden). I am not sure if this is due > to Xorg or other programs. I don't know what you're using for Mod4, but X doesn't intercept any two-key bindings on its own. Some three-key, but no two-key. Occasionally the platform firmware will intercept some combinations, but typically that doesn't affect cursor visibility (instead it's more like "change display configuration" or "increase brightness"), so I would expect this is a function of your desktop environment. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: git access to sgi / xf86-video-impact
On Tue, 2018-10-16 at 17:02 +0200, René Rebe wrote: > I now requested access (rener) on the new gitlab site. The top-level 'xorg' group implies access to all subprojects, which we'd like to keep to a minimum. I've added you as a Maintainer to xorg/drivers/xf86-video-impact, if you need additional access to other projects we can add that as we go. Welcome aboard! - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
gitlab migration: xserver issues enabled
I've enabled filing gitlab issues for xserver, as people were trying to file bugs against xorg/meta (which is not the right place). Expect bugzilla migration to start happening later this week and take... well, I don't know how long, I'll be attempting to triage/close old issues as I go and I don't have a good estimate for how long that'll take. If you're getting notifications for xorg issues from gitlab, and haven't set up your mail filters yet, now would be an excellent time to do that. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xfree86: Only switch to original VT if it is active.
On Thu, 2018-10-11 at 16:45 +0200, Michal Srb wrote:
> If the X server is terminated while its VT is not active, it should
> not change the current VT.
> ---
> Changing the VT in that situation serves no purpose and can be confusing.
> For example when a user's graphical session is terminated while other
> user is using the computer, it would switch the VT he is working on.
Conceptual ack. Would slightly prefer to see this done by
VT_GETSTATE/VT_GETACTIVE ioctl (depending which OS you're on). It
should be simpler, and also...
> diff --git a/hw/xfree86/common/xf86Privstr.h b/hw/xfree86/common/xf86Privstr.h
> index 55d1b2455..e4d827dee 100644
> --- a/hw/xfree86/common/xf86Privstr.h
> +++ b/hw/xfree86/common/xf86Privstr.h
> @@ -61,6 +61,7 @@ typedef struct {
> Bool dontVTSwitch;
> Bool autoVTSwitch;
> Bool ShareVTs;
> +Bool hasVT;
> Bool dontZap;
> Bool dontZoom;
... this struct is ABI (sigh) so the fix would be unsuitable for a
stable release.
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver v8 05/14] modesetting: Use atomic modesetting API for pageflip if available
On Mon, 2018-10-01 at 11:31 -0400, Adam Jackson wrote:
> AFAICT the free(dst) is always wrong. The other places we use
> drmmode_prop_info_copy, we're initializing an array in the middle of a
> drmmode_{crtc,output}_private_rec.
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/33
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver v8 05/14] modesetting: Use atomic modesetting API for pageflip if available
On Wed, 2018-09-12 at 11:01 +1000, Dave Airlie wrote:
> On Wed, 28 Feb 2018 at 11:21, Daniel Stone wrote:
> >
> > +static Bool
> > +drmmode_prop_info_copy(drmmode_prop_info_ptr dst,
> > + const drmmode_prop_info_rec *src,
> > + unsigned int num_props,
> > + Bool copy_prop_id)
> > +{
> > +unsigned int i;
> > +
> > +memcpy(dst, src, num_props * sizeof(*dst));
> > +
> > +for (i = 0; i < num_props; i++) {
> > +unsigned int j;
> > +
> > +if (copy_prop_id)
> > +dst[i].prop_id = src[i].prop_id;
> > +else
> > +dst[i].prop_id = 0;
> > +
> > +if (src[i].num_enum_values == 0)
> > +continue;
> > +
> > +dst[i].enum_values =
> > +malloc(src[i].num_enum_values *
> > +sizeof(*dst[i].enum_values));
> > +if (!dst[i].enum_values)
> > +goto err;
> > +
> > +memcpy(dst[i].enum_values, src[i].enum_values,
> > +src[i].num_enum_values * sizeof(*dst[i].enum_values));
> > +
> > +for (j = 0; j < dst[i].num_enum_values; j++)
> > +dst[i].enum_values[j].valid = FALSE;
> > +}
> > +
> > +return TRUE;
> > +
> > +err:
> > +while (i--)
> > +free(dst[i].enum_values);
> > +free(dst);
> > +return FALSE;
> > +}
>
> On failure this frees dst, however...
>
> > +drmmode_crtc_create_planes(xf86CrtcPtr crtc, int num)
> > +{
> > +drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
> > +drmmode_ptr drmmode = drmmode_crtc->drmmode;
> > +drmModePlaneRes *kplane_res;
> > +drmModePlane *kplane;
> > +drmModeObjectProperties *props;
> > +uint32_t i, type;
> > +int current_crtc, best_plane = 0;
> > +
> > +static drmmode_prop_enum_info_rec plane_type_enums[] = {
> > +[DRMMODE_PLANE_TYPE_PRIMARY] = {
> > +.name = "Primary",
> > +},
> > +[DRMMODE_PLANE_TYPE_OVERLAY] = {
> > +.name = "Overlay",
> > +},
> > +[DRMMODE_PLANE_TYPE_CURSOR] = {
> > +.name = "Cursor",
> > +},
> > +};
> > +static const drmmode_prop_info_rec plane_props[] = {
> > +[DRMMODE_PLANE_TYPE] = {
> > +.name = "type",
> > +.enum_values = plane_type_enums,
> > +.num_enum_values = DRMMODE_PLANE_TYPE__COUNT,
> > +},
> > +[DRMMODE_PLANE_FB_ID] = { .name = "FB_ID", },
> > +[DRMMODE_PLANE_CRTC_ID] = { .name = "CRTC_ID", },
> > +[DRMMODE_PLANE_SRC_X] = { .name = "SRC_X", },
> > +[DRMMODE_PLANE_SRC_Y] = { .name = "SRC_Y", },
> > +};
> > +drmmode_prop_info_rec tmp_props[DRMMODE_PLANE__COUNT];
>
> We use a stack allocated tmp_props here.
AFAICT the free(dst) is always wrong. The other places we use
drmmode_prop_info_copy, we're initializing an array in the middle of a
drmmode_{crtc,output}_private_rec.
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver v2] glamor: add support for NV12 in Xv
On Tue, 2018-09-11 at 15:41 -0400, Alex Deucher wrote: > On Tue, Sep 11, 2018 at 1:30 PM Julien Isorce wrote: > > > > Useful when video decoders only output NV12. Currently > > glamor Xv only supports I420 and YV12. > > > > Note that Intel's sna supports I420, YV12, YUY2, UYVY, NV12. > > > > Test: xvinfo | grep NV12 > > Test: gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12 ! xvimagesink > > > > v2: Combine the two texture2Ds on u_sampler. > > > > Signed-off-by: Julien Isorce > > Reviewed-by: Alex Deucher Merged the series, thanks. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab merge requests are (mostly) enabled
On Mon, 2018-09-10 at 10:28 -0400, Adam Jackson wrote: > If you haven't logged into patchwork yet and turned on notifications ^ Erk, that should say gitlab not patchwork. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
gitlab merge requests are (mostly) enabled
I've turned merge requests on for most modules. I haven't done the drivers yet (hopefully by the end of the day), and will continue to leave them disabled for the drivers whose maintainers have asked they be left disabled. In particular, merge requests are enabled for xserver now, and that's how I'll be managing the merges I do. If you've forked xserver in gitlab and push to your repo, you'll see a link to create a merge request for that branch, like so: remote: To create a merge request for patchwork-246007, visit: remote: https://gitlab.freedesktop.org/ajax/xserver/merge_requests/new?merge_request%5Bsource_branch%5D=patchwork-246007 remote: To gitlab.freedesktop.org:ajax/xserver.git * [new branch]patchwork-246007 -> patchwork-246007 This has the advantage of running the CI pipeline automatically. I strongly encourage others to use the MR workflow as much as possible. I make no promises about patches sent only to the mailing list, and any such that I do pay attention to will be proxied into merge requests (as above). If you haven't logged into patchwork yet and turned on notifications for the modules and groups you're interested in, now would be a good time to do that. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Pixman] [BUG] SIGSEGV in sse2_fill
continued from pixman@, original thread here: https://lists.freedesktop.org/archives/pixman/2018-August/004759.html On Wed, 2018-08-29 at 18:14 +0200, Frédéric Fauberteau wrote: > Le 2018-08-29 16:33, Adam Jackson a écrit : > > This is a curious backtrace though. You're crashing while trying to > > draw the black solid fill for the initial map of the root window. Fine, > > but you're doing so in software, even though you have glamor enabled, > > and glamor surely can usually accelerate solid fills. So you're hitting > > a software fallback for some reason, and if I had to guess... > > The area to fill is 2960x1050 but actually, I have two screens: > - - > > | | | > > | | | > > 1680x1050 | | 1280x1024 | > > | | | > > | |---| > > - > > Do you think it could be a reason to write in an unmapped region...? Probably not? Typically the allocation for the root window is a rectangle big enough to bound all the outputs within it, so actually 2960x1050 in your case. The missing corner below the 1280x1024 display still has memory behind it. > It is a RS780/RS880 (Radeon HD 3200). If the bug comes from the Mesa > driver, it's a big issue since we are totally late with the update (we > are on MesaLib 11.2.2) That should be new enough to not have the problem I was describing. Unfortunately, that means I'm out of ideas. I think there are probably at least two bugs here: the fallback shouldn't crash, but neither should the fallback occur. Probably the second one is a bit easier to figure out. I'd start by rebuilding xserver with some printf-debugging in the body of glamor_poly_fill_rect_gl(), to see which 'goto bail' path is getting hit. (xserver spells printf ErrorF, which will print into both the X log and stdout.) - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PULL xserver] Remove old colormap special cases from xfree86
This makes xf86 colormap setup not as weird as other DDXes, and removes matching special-casing from the devPrivate system. The trident and xgixp drivers would be affected by this, losing the ability to set the overscan border color. Either user is encouraged to speak up. The following changes since commit 1fc20b985cc888345bc8c6fce7b43f10ce71fe43: meson: Add detection of libsystemd-daemon. (2018-08-09 13:42:54 -0400) are available in the Git repository at: ssh://g...@gitlab.freedesktop.org/ajax/xserver xf86cmap for you to fetch changes up to 5e01650d190fa046a53139a4955b0ef7aedcbaad: xfree86: Remove the rest of ->SetOverscan (2018-08-20 14:55:35 -0400) ---- Adam Jackson (8): xf86cmap: Factor out private lookup xf86cmap: Remove numColors from the colormap private xf86cmap: Remove overscan machinery xf86cmap: Always recalculate colors xf86cmap: Compute colors as needed xf86cmap: Remove the colormap private dix: Remove colormap private fixup xfree86: Remove the rest of ->SetOverscan dix/privates.c | 21 +--- hw/xfree86/common/xf86Init.c | 2 - hw/xfree86/common/xf86cmap.c | 322 -- hw/xfree86/common/xf86cmap.h | 2 +- hw/xfree86/common/xf86str.h | 2 - hw/xfree86/doc/ddxDesign.xml | 27 +- hw/xfree86/vgahw/vgaHW.c | 30 +- include/privates.h | 2 +- 8 files changed, 50 insertions(+), 358 deletions(-) - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
gitlab group permissions update
gitlab groups are recursive, which means if you are a member of the 'xorg' group, your permission level for every project in that group is at least as high as your permission at the top level. Most of the existing accounts were set as Maintainer, at which level you can do things like read and set the secret tokens used for web API integrations, which is maybe a little too permissive in general. I've bumped most people down to Developer, which is still enough to do things like close issues and merge MRs. The difference is essentially that Maintainers can modify the gitlab environment of a project, in addition to just the project's content like a Developer. If you need higher access for your subprojects, give a shout. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Anyone have a backup of XFree86 CVS?
On Mon, 2018-02-05 at 17:00 -0500, Adam Jackson wrote: > Well that was fast! Got a copy of the cvsroot for 3.x/4.x, hooray. I'll > take a crack at importing that to git once xserver 1.20 is out. https://gitlab.freedesktop.org/ajax/xfree86 - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On Mon, 2018-06-11 at 12:33 +0200, Michel Dänzer wrote: > As the maintainer of xf86-video-amdgpu and -ati, I'm fine with migrating > these to GitLab for Git and patch review. > > However, I'm not sure what to do about bugs/issues. My first thought was > to allow creating new issues in GitLab and disable creating new reports > in Bugzilla, but not to migrate existing reports from Bugzilla. However, > it still happens fairly often that a report is initially filed against > the Xorg drivers, even though it's actually an issue in the X server, > Mesa or the kernel (old habits die hard...). Therefore, I'm inclined to > stick to Bugzilla until at least the X server and Mesa have moved to > GitLab for issue tracking, to hopefully allow moving such misfiled issues. I've hacked up the migration script to allow moving individual issues by bug number instead of matching a whole product/component [1]. This has already been useful to sort out some of the junkdrawer components like App/Other. Running the script does require someone with supercow powers on both sides, but I'm happy to do so as needed. With that in mind, I think it may be time to enable issues and merge requests for xserver, and disable the remaining (server) bz components for new issues. Any objections? [1] - https://gitlab.freedesktop.org/freedesktop/bztogl/merge_requests/1 - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 10/10] meson: Add detection of libsystemd-daemon.
On Wed, 2018-08-08 at 10:37 +1000, Peter Hutterer wrote: > but either way, series is > Reviewed-by: Peter Hutterer Merged (except 6/10), thanks: remote: remote: I: patch #243247 updated using rev 513d52d58915f291c0f706b67b8dc73f45de109f. remote: remote: I: patch #243245 updated using rev 843e44adf17b2828991a26ac3f8f82cf2fa63bd3. remote: remote: I: patch #243246 updated using rev 9869512cbf1bd87146f59106c0c71bda76cc0dcc. remote: remote: I: patch #243244 updated using rev db53c439ba785a16f789918fe66da6ba161a0742. remote: remote: I: patch #243249 updated using rev 97bd8bc9cb6d910420627760288696e2a0c5d226. remote: remote: I: patch #243248 updated using rev 049d2346abee091f18e6f62bcf7331267c2ba656. remote: remote: I: patch #243250 updated using rev e047da37becc23a8d2549d8f264aaa18e4965186. remote: remote: I: patch #243252 updated using rev 4ba786677050684c8801201f6bd83ce884f2885e. remote: remote: I: patch #243251 updated using rev 1fc20b985cc888345bc8c6fce7b43f10ce71fe43. remote: remote: I: 9 patch(es) updated to state Accepted. remote: To ssh://kemper.freedesktop.org/git/xorg/xserver remote:d0545847a..1fc20b985 1fc20b985cc888345bc8c6fce7b43f10ce71fe43 -> master To ssh://gitlab.freedesktop.org/xorg/xserver d0545847a0..1fc20b985c master -> master - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 06/10] meson: Add an option to build XSELINUX.
On Tue, 2018-08-07 at 16:23 -0700, Eric Anholt wrote:
> Dependencies are ported from the automake build. The only part I
> skipped was making sure we can find libaudit.h.
Fair enough, but then:
> +build_xselinux = get_option('xselinux')
> +if build_xselinux
> +if not build_xace
> +error('cannot build XSELINUX extension without X-ACE')
> +endif
> +common_dep += dependency('libselinux', version: '>= 2.0.86')
> +common_dep += cc.find_library('audit')
> +endif
This can be dependency('audit'), there's a pkgconfig file. I think this
might want to be automatic based on linux && dependency() though,
because...
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -78,6 +78,8 @@ option('xres', type: 'boolean', value: true,
> description: 'XRes extension')
> option('xace', type: 'boolean', value: true,
> description: 'X-ACE extension')
> +option('xselinux', type: 'boolean', value: true,
> + description: 'XSELINUX extension')
(... until/unless we require a newer meson with better 'auto' support,)
non-Linux (and non-SELinux-using Linux) systems will have to explicitly
disable something they can't possibly use just to build. This happened
to me, even:
https://ci.appveyor.com/project/nwnk/xserver/build/job/hf8rxt84upie2wpq
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] autotools: Handle case when bindir var in xkbcomp.pc is absent
On Thu, 2018-08-09 at 12:25 -0400, Adam Jackson wrote: > From: "vadym.shovkoplias" Apologies to Vadym, who had tried to send the same thing to the list but got blocked by moderation. > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107521 > Fixes: 726839459cb (autotools: Derive xkb configuration from xkbcomp.pc) > > Signed-off-by: vadym.shovkoplias Merged, thanks: remote: remote: I: patch #243732 updated using rev d0545847a06f375586927ea66c521a039439f708. remote: remote: I: 1 patch(es) updated to state Accepted. remote: To ssh://kemper.freedesktop.org/git/xorg/xserver remote:4fe02b8da..d0545847a d0545847a06f375586927ea66c521a039439f708 -> master To ssh://gitlab.freedesktop.org/xorg/xserver 4fe02b8da3..d0545847a0 master -> master - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] autotools: Handle case when bindir var in xkbcomp.pc is absent
From: "vadym.shovkoplias"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107521
Fixes: 726839459cb (autotools: Derive xkb configuration from xkbcomp.pc)
Signed-off-by: vadym.shovkoplias
---
configure.ac | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 350c89a3bf..f547b1dc9b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1404,7 +1404,10 @@ AC_ARG_WITH(xkb-bin-directory,
[XKB_BIN_DIRECTORY="auto"])
if test "x$XKB_BIN_DIRECTORY" = "xauto"; then
-XKB_BIN_DIRECTORY=$(pkg-config --variable bindir xkbcomp || echo ${bindir})
+XKB_BIN_DIRECTORY=$(pkg-config --variable bindir xkbcomp)
+if test -z $XKB_BIN_DIRECTORY; then
+XKB_BIN_DIRECTORY="$bindir"
+fi
fi
AC_DEFINE_DIR(XKB_BIN_DIRECTORY, XKB_BIN_DIRECTORY, [Path to XKB bin dir])
--
2.17.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
gitlab archives (was Re: [PATCH app/luit] Retire this fork of luit)
On Tue, 2018-08-07 at 12:03 -0400, Adam Jackson wrote: > We're not seriously maintaining this tool, we should stop pretending. > > Signed-off-by: Adam Jackson Merged (and archived the project): remote: remote: I: patch #243108 updated using rev 2aaa5d75f1b92a5383af676dbd7f0998e26023ac. remote: remote: I: 1 patch(es) updated to state Accepted. remote: To ssh://kemper.freedesktop.org/git/xorg/app/luit remote:e209207..2aaa5d7 2aaa5d75f1b92a5383af676dbd7f0998e26023ac -> master To gitlab.freedesktop.org:xorg/app/luit.git e209207..2aaa5d7 master -> master I've only cc'd the list about this patch because it's pointing people elsewhere and not just archiving. Future archivals will be tracked with gitlab issues. gitlab doesn't make it easy to see archived projects recursively through subgroups, so there is a centralized list here: https://gitlab.freedesktop.org/xorg/meta/wikis/archives That page (and wiki) is also probably temporary, we should eventually move off the old wiki and restructure a lot of our documentation anyway. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH app/luit] Retire this fork of luit
We're not seriously maintaining this tool, we should stop pretending. Signed-off-by: Adam Jackson --- README | 27 +-- 1 file changed, 5 insertions(+), 22 deletions(-) diff --git a/README b/README index 825d09e..f60d34f 100644 --- a/README +++ b/README @@ -3,26 +3,9 @@ a UTF-8 terminal emulator such as xterm. It will convert application output from the locale's encoding into UTF-8, and convert terminal input from UTF-8 into the locale's encoding. -All questions regarding this software should be directed at the -Xorg mailing list: - -http://lists.freedesktop.org/mailman/listinfo/xorg - -Please submit bug reports to the Xorg bugzilla: - -https://bugs.freedesktop.org/enter_bug.cgi?product=xorg - -The master development code repository can be found at: - -git://anongit.freedesktop.org/git/xorg/app/luit - -http://cgit.freedesktop.org/xorg/app/luit - -For patch submission instructions, see: - - http://www.x.org/wiki/Development/Documentation/SubmittingPatches - -For more information on the git code manager, see: - -http://wiki.x.org/wiki/GitPage +This particular version of luit is vestigial. It's been hacked at +randomly since X.Org 6.7, but is not actively maintained and has +known issues. You are almost certainly better off using Thomas Dickey's +version, which can be found at: +http://invisible-island.net/luit/ -- 2.17.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 6/6] meson: Automatically detect HAVE_PTHREAD_SETNAME_NP
On Thu, 2018-08-02 at 15:22 +1000, Peter Hutterer wrote: > On Wed, Aug 01, 2018 at 01:49:54PM -0700, Eric Anholt wrote: > > Signed-off-by: Eric Anholt > > series Reviewed-by: Peter Hutterer 4/6 doesn't go too far enough, but this all looks good. Merged, thanks: remote: remote: I: patch #242143 updated using rev e3e5265743a3536f15c8b7ae521848a646cdc189. remote: remote: I: patch #242146 updated using rev 7deaf990079b94c70d263d8f1e16bb954bd2917f. remote: remote: I: patch #242144 updated using rev 708ddfbda1391468d66957e247f51854b39db5fa. remote: remote: I: patch #242145 updated using rev accd32a466a1a87ab45b5422dff2ef5a9c867049. remote: remote: I: patch #242148 updated using rev 86c9245838b95e8a0c37fa61d835112933c738f0. remote: remote: I: patch #242147 updated using rev c20e7b5ec0cae2a487264748fa5db711e6e4. remote: remote: I: 6 patch(es) updated to state Accepted. remote: To ssh://kemper.freedesktop.org/git/xorg/xserver remote:1ef7aed3e..c20e7b5e2 c20e7b5ec0cae2a487264748fa5db711e6e4 -> master To ssh://gitlab.freedesktop.org/xorg/xserver 1ef7aed3e2..c20e7b5e22 master -> master - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xserver: Changes to 'server-1.20-branch'
On Thu, 2018-08-02 at 10:47 +0200, Michel Dänzer wrote: > On 2018-08-01 08:10 PM, GitLab Mirror wrote: > > New branch 'server-1.20-branch' available with the following commits: > > I'd like to nominate https://patchwork.freedesktop.org/patch/232490/ for > 1.20.1 as well. Hrargh. That patch doesn't show up in patchwork if you say "pwclient list -s new xserver", because patchwork takes the subject line from the email not the patch. Once you apply the fixed version, it can't find the patch in its own database either, so you have to mark it Accepted by hand. I am extremely ready to not use email for patch management anymore. Thanks for pointing that patch out, I'd have missed it. I was initially suspicious of the ms driver change, but there's no way the driver can get this right _without_ the server change, so I'm for it. Merged to master, thanks: remote: remote: E: failed to find patch for rev 1ef7aed3e2bb2af32330f19b1e756512ddfe. remote: remote: I: 0 patch(es) updated to state Accepted. remote: To ssh://kemper.freedesktop.org/git/xorg/xserver remote:d625e1691..1ef7aed3e 1ef7aed3e2bb2af32330f19b1e756512ddfe -> master To ssh://gitlab.freedesktop.org/xorg/xserver d625e16918..1ef7aed3e2 master -> master Will cherry-pick to 1.20 shortly. > Also, it would be nice if somebody who cares about the modesetting > driver could fix https://bugs.freedesktop.org/101998#c37 . I was about > to get fed up with it enough to do it myself, but I might not get around > to it for a couple of weeks. I think I can take a crack at that. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
On Wed, 2018-08-01 at 14:38 +0200, Guillem Jover wrote: > It would be nice if the xorg.modules (from modular) got updated too, so > that some of this could be automated locally. :) My goodness, we have written this down so many slightly different ways. I've pushed some updates that I hope are right since I don't know of anything actually using that file, let me know if anything looks wrong or you need more. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH app/fonttosfnt 2/5] README: update repository URL to gitlab
On Tue, 2018-07-31 at 11:53 +1000, Peter Hutterer wrote: > Signed-off-by: Peter Hutterer > --- > README | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Reviewed-by: Adam Jackson And a pre-emptive r-b for the same change to every other repo, I suppose. I can script that, if nobody beats me to it. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xmodmap really slow
On Thu, 2018-07-26 at 12:25 +0100, Alan Hourihane wrote: > Anyone tried just doing this recently > > xmodmap -pke > /tmp/keydump > xmodmap /tmp/keydump > > And watch the Xserver hang for quite some time. Seems to be nearly instantaneous against an Xvfb, but did cause a noticable hiccup with Xorg. Haven't investigated more closely, so I'd suspect (in rough order of likelihood): a) something super-linear in the number of input devices b) some weird slow ioctl syncing the X state to the kernel c) somehow you end up on the "lets spawn xkbcomp" path and the fork/exec overhead kills you - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
More gitlab migration (this time it's personal)
If you want to follow anything I'm working on, follow it here: https://gitlab.freedesktop.org/ajax/xserver/ I'll be using merge requests under that repo to track the progress of my own development branches, and issues to track known defects that someone should work on. I won't be looking at bugzilla except to move issues into gitlab (or close them), and I'll only be sending pull requests to this list pointing to branches I'd like to merge. If you'd like an easy way to track these merge requests as just another remote, check out util/modular/add-gitlab-merge-requests.sh: ~/git/xserver$ git remote add ajax https://gitlab.freedesktop.org/ajax/xserver/ ~/git/xserver$ ~/git/util-modular/add-gitlab-merge-requests.sh ajax ajax-merge-requests This is sort of a trial run for doing issues and MRs for xorg/xserver proper. Once we move to that (hopefully ASAP): a) my merge requests would be only for work-in-progress, and I'd reassign them to xorg/xserver when I think they're plausible to merge b) my issues would only be things I am working, or intend to work, on - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: modesetting: Fix cirrus 24bpp breakage
On Thu, 2018-07-19 at 14:38 +0200, Stefan Dirsch wrote: > From: Takashi Iwai > > The recent rewrite of modesetting driver broke the 24bpp support. > As typically found on cirrus KMS, it leads to a blank screen, spewing > the error like: > failed to add fb -22 > (EE) modeset(0): failed to set mode: Invalid argument > > The culript is that the wrong bpp value of the front buffer is passed > to drmModeAddFB(). Fix it by replacing with the back buffer bpp, > drmmode->kbpp. > > Signed-off-by: Takashi Iwai > Tested-by: Stefan Dirsch Merged, thanks: remote: remote: I: patch #239767 updated using rev d625e16918ef9104863709eb108346464767c444. remote: remote: I: 1 patch(es) updated to state Accepted. remote: To ssh://kemper.freedesktop.org/git/xorg/xserver remote:cdec2b3c1..d625e1691 d625e16918ef9104863709eb108346464767c444 -> master To ssh://gitlab.freedesktop.org/xorg/xserver cdec2b3c1..d625e1691 master -> master - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 xserver] xwayland: Enable DRI3 for glamor
On Wed, 2018-07-25 at 16:33 +0200, Olivier Fourdan wrote:
> glamor_fds_from_pixmap() will bail out early if DRI3 is not enabled,
> unfortunately Xwayland's glamor code would not set it as enabled which
> would lead to blank pixmaps when using texture from pixmap.
>
> Make sure to mark DRI3 as enabled from glamor_egl_screen_init() in
> Xwayland.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107287
> Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and
> BuffersFromPixmap")
> Signed-off-by: Olivier Fourdan
> Reviewed-by: Michel Dänzer
Merged, thanks:
remote: remote: I: patch #239943 updated using rev
cdec2b3c195d1d080207ef01c55ff14b45370010.
remote: remote: I: 1 patch(es) updated to state Accepted.
remote: To ssh://kemper.freedesktop.org/git/xorg/xserver
remote:ce2dde9ed..cdec2b3c1 cdec2b3c195d1d080207ef01c55ff14b45370010 ->
master
To ssh://gitlab.freedesktop.org/xorg/xserver
ce2dde9ed..cdec2b3c1 master -> master
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver v2] xwayland: rotate logical size for RRMode
On Thu, 2018-07-19 at 09:18 +0200, Olivier Fourdan wrote: > Hi, > > On Mon, Jul 16, 2018 at 10:47 AM Simon Ser wrote: > > > Reviewed-by: Olivier Fourdan Merged, thanks: remote: remote: I: patch #238455 updated using rev ce2dde9ed0243a18ae18af0879134f7c1afbd700. remote: remote: I: 1 patch(es) updated to state Accepted. remote: To ssh://kemper.freedesktop.org/git/xorg/xserver remote:93cafb082..ce2dde9ed ce2dde9ed0243a18ae18af0879134f7c1afbd700 -> master To ssh://gitlab.freedesktop.org/xorg/xserver 93cafb082..ce2dde9ed master -> master - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 7/7] composite: Implement backing store's Always mode
Keep the pixmap at unmap, always try to realize backing store, always
mark them when marking, and update paintable when backed.
Signed-off-by: Adam Jackson
---
composite/compalloc.c | 2 +-
composite/compinit.c | 24 +++--
composite/compint.h| 8 ++
composite/compwindow.c | 61 --
4 files changed, 90 insertions(+), 5 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index 433dc820a4..7484b55818 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -111,7 +111,7 @@ compMarkWindows(WindowPtr pWin, WindowPtr *ppLayerWin)
ScreenPtr pScreen = pWin->drawable.pScreen;
WindowPtr pLayerWin = pWin;
-if (!pWin->viewable)
+if (!pWin->viewable && pWin->backingStore != Always)
return FALSE;
(*pScreen->MarkOverlappedWindows) (pWin, pWin, );
diff --git a/composite/compinit.c b/composite/compinit.c
index 2590aa46df..c02c8f31b5 100644
--- a/composite/compinit.c
+++ b/composite/compinit.c
@@ -67,6 +67,7 @@ compCloseScreen(ScreenPtr pScreen)
pScreen->ConfigNotify = cs->ConfigNotify;
pScreen->MoveWindow = cs->MoveWindow;
pScreen->ResizeWindow = cs->ResizeWindow;
+pScreen->MarkUnrealizedWindow = cs->MarkUnrealizedWindow;
pScreen->ChangeBorderWidth = cs->ChangeBorderWidth;
pScreen->ClipNotify = cs->ClipNotify;
@@ -74,6 +75,7 @@ compCloseScreen(ScreenPtr pScreen)
pScreen->RealizeWindow = cs->RealizeWindow;
pScreen->DestroyWindow = cs->DestroyWindow;
pScreen->CreateWindow = cs->CreateWindow;
+pScreen->WindowExposures = cs->WindowExposures;
pScreen->CopyWindow = cs->CopyWindow;
pScreen->PositionWindow = cs->PositionWindow;
@@ -105,14 +107,26 @@ compInstallColormap(ColormapPtr pColormap)
pScreen->InstallColormap = compInstallColormap;
}
+static void
+compCheckPaintable(WindowPtr pWin)
+{
+pWin->paintable = pWin->viewable || pWin->backingStore == Always;
+}
+
static void
compCheckBackingStore(WindowPtr pWin)
{
-if (pWin->backingStore != NotUseful && !pWin->backStorage) {
+Bool should =
+(pWin->backingStore == Always) ||
+(pWin->backingStore == WhenMapped && pWin->viewable);
+
+if (should && !pWin->backStorage) {
+compCheckPaintable(pWin);
compRedirectWindow(serverClient, pWin, CompositeRedirectAutomatic);
pWin->backStorage = TRUE;
}
-else if (pWin->backingStore == NotUseful && pWin->backStorage) {
+else if (!should && pWin->backStorage) {
+compCheckPaintable(pWin);
compUnredirectWindow(serverClient, pWin,
CompositeRedirectAutomatic);
pWin->backStorage = FALSE;
@@ -418,6 +432,9 @@ compScreenInit(ScreenPtr pScreen)
cs->UnrealizeWindow = pScreen->UnrealizeWindow;
pScreen->UnrealizeWindow = compUnrealizeWindow;
+cs->WindowExposures = pScreen->WindowExposures;
+pScreen->WindowExposures = compWindowExposures;
+
cs->ClipNotify = pScreen->ClipNotify;
pScreen->ClipNotify = compClipNotify;
@@ -430,6 +447,9 @@ compScreenInit(ScreenPtr pScreen)
cs->ResizeWindow = pScreen->ResizeWindow;
pScreen->ResizeWindow = compResizeWindow;
+cs->MarkUnrealizedWindow = pScreen->MarkUnrealizedWindow;
+pScreen->MarkUnrealizedWindow = compMarkUnrealizedWindow;
+
cs->ChangeBorderWidth = pScreen->ChangeBorderWidth;
pScreen->ChangeBorderWidth = compChangeBorderWidth;
diff --git a/composite/compint.h b/composite/compint.h
index 89f6507b95..a4d56f2828 100644
--- a/composite/compint.h
+++ b/composite/compint.h
@@ -131,6 +131,7 @@ typedef struct _CompScreen {
DestroyWindowProcPtr DestroyWindow;
RealizeWindowProcPtr RealizeWindow;
UnrealizeWindowProcPtr UnrealizeWindow;
+WindowExposuresProcPtr WindowExposures;
ClipNotifyProcPtr ClipNotify;
/*
* Called from ConfigureWindow, these
@@ -140,6 +141,7 @@ typedef struct _CompScreen {
ConfigNotifyProcPtr ConfigNotify;
MoveWindowProcPtr MoveWindow;
ResizeWindowProcPtr ResizeWindow;
+MarkUnrealizedWindowProcPtr MarkUnrealizedWindow;
ChangeBorderWidthProcPtr ChangeBorderWidth;
/*
* Reparenting has an effect on Subwindows redirect
@@ -290,6 +292,9 @@ Bool
Bool
compUnrealizeWindow(WindowPtr pWin);
+void
+compWindowExposures(WindowPtr pWin, RegionPtr reg);
+
void
compClipNotify(WindowPtr pWin, int dx, int dy);
@@ -301,6 +306,9 @@ void
compResizeWindow(WindowPtr pWin, int x, int y,
unsigned int w, unsigned int h, WindowPtr pSib);
+void
+ compMarkUnrealizedWindow(WindowPtr pChild, WindowPtr pWin, Bool
fromConfigure);
+
void
compChangeBorderWidth(WindowPtr pWin, unsigned int border_width);
diff --git a/
[PATCH xserver 5/7] dix: Update window state based on paintable not viewable
Signed-off-by: Adam Jackson
---
dix/window.c | 69
1 file changed, 32 insertions(+), 37 deletions(-)
diff --git a/dix/window.c b/dix/window.c
index ea3920c869..55290577d9 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -1589,7 +1589,7 @@ ChangeWindowAttributes(WindowPtr pWin, Mask vmask, XID
*vlist, ClientPtr client)
for the tile to be rotated, and the correct function selected.
*/
if (((vmaskCopy & (CWBorderPixel | CWBorderPixmap)) || borderRelative)
-&& pWin->viewable && HasBorder(pWin)) {
+&& pWin->paintable && HasBorder(pWin)) {
RegionRec exposed;
RegionNull();
@@ -2163,7 +2163,7 @@ ReflectStackChange(WindowPtr pWin, WindowPtr pSib, VTKind
kind)
{
/* Note that pSib might be NULL */
-Bool WasViewable = (Bool) pWin->viewable;
+Bool WasPaintable = (Bool) pWin->paintable;
Bool anyMarked;
WindowPtr pFirstChange;
WindowPtr pLayerWin;
@@ -2175,7 +2175,7 @@ ReflectStackChange(WindowPtr pWin, WindowPtr pSib, VTKind
kind)
pFirstChange = MoveWindowInStack(pWin, pSib);
-if (WasViewable) {
+if (WasPaintable) {
anyMarked = (*pScreen->MarkOverlappedWindows) (pWin, pFirstChange,
);
if (pLayerWin != pWin)
@@ -2614,7 +2614,7 @@ RealizeTree(WindowPtr pWin)
pChild = pWin;
while (1) {
if (pChild->mapped) {
-pChild->realized = TRUE;
+pChild->realized = pChild->parent->realized;
pChild->viewable = (pChild->drawable.class == InputOutput);
pChild->paintable = (pChild->drawable.class == InputOutput);
(*Realize) (pChild);
@@ -2692,7 +2692,7 @@ MapWindow(WindowPtr pWin, ClientPtr client)
if (SubStrSend(pWin, pParent))
DeliverMapNotify(pWin);
-if (!pParent->realized)
+if (!pParent->realized && !pParent->paintable)
return Success;
RealizeTree(pWin);
if (pWin->viewable) {
@@ -2763,7 +2763,7 @@ MapSubwindows(WindowPtr pParent, ClientPtr client)
if (!pFirstMapped)
pFirstMapped = pWin;
-if (pParent->realized) {
+if (pParent->realized || pParent->paintable) {
RealizeTree(pWin);
if (pWin->viewable) {
anyMarked |= (*pScreen->MarkOverlappedWindows) (pWin, pWin,
@@ -2861,7 +2861,7 @@ UnmapWindow(WindowPtr pWin, Bool fromConfigure)
{
WindowPtr pParent;
Bool wasRealized = (Bool) pWin->realized;
-Bool wasViewable = (Bool) pWin->viewable;
+Bool wasPaintable = pWin->paintable;
ScreenPtr pScreen = pWin->drawable.pScreen;
WindowPtr pLayerWin = pWin;
@@ -2869,7 +2869,7 @@ UnmapWindow(WindowPtr pWin, Bool fromConfigure)
return Success;
if (SubStrSend(pWin, pParent))
DeliverUnmapNotify(pWin, fromConfigure);
-if (wasViewable && !fromConfigure) {
+if (wasPaintable && !fromConfigure) {
pWin->valdata = UnmapValData;
(*pScreen->MarkOverlappedWindows) (pWin, pWin->nextSib, );
(*pScreen->MarkWindow) (pLayerWin->parent);
@@ -2877,13 +2877,11 @@ UnmapWindow(WindowPtr pWin, Bool fromConfigure)
pWin->mapped = FALSE;
if (wasRealized)
UnrealizeTree(pWin, fromConfigure);
-if (wasViewable) {
-if (!fromConfigure) {
-(*pScreen->ValidateTree) (pLayerWin->parent, pWin, VTUnmap);
-(*pScreen->HandleExposures) (pLayerWin->parent);
-if (pScreen->PostValidateTree)
-(*pScreen->PostValidateTree) (pLayerWin->parent, pWin,
VTUnmap);
-}
+if (wasPaintable && !fromConfigure) {
+(*pScreen->ValidateTree) (pLayerWin->parent, pWin, VTUnmap);
+(*pScreen->HandleExposures) (pLayerWin->parent);
+if (pScreen->PostValidateTree)
+(*pScreen->PostValidateTree) (pLayerWin->parent, pWin, VTUnmap);
}
if (wasRealized && !fromConfigure) {
WindowsRestructured();
@@ -2903,7 +2901,7 @@ UnmapSubwindows(WindowPtr pWin)
{
WindowPtr pChild, pHead;
Bool wasRealized = (Bool) pWin->realized;
-Bool wasViewable = (Bool) pWin->viewable;
+Bool wasPaintable = pWin->paintable;
Bool anyMarked = FALSE;
Mask parentNotify;
WindowPtr pLayerWin = NULL;
@@ -2914,7 +2912,7 @@ UnmapSubwindows(WindowPtr pWin)
parentNotify = SubSend(pWin);
pHead = RealChildHead(pWin);
-if (wasViewable)
+if (wasPaintable)
pLayerWin = (*pScreen->GetLayerWindow) (pWin);
for (pChild = pWin->lastChild; pChild != pHead; pChild = pChild->prevSib) {
@@ -2930,31 +2928,28 @@ UnmapSubwindows(WindowPtr pWin)
Unreal
[PATCH xserver 3/7] mi: Mark/validate based on paintable not viewable
Signed-off-by: Adam Jackson
---
mi/miwindow.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/mi/miwindow.c b/mi/miwindow.c
index 39c279e184..1b910d9bea 100644
--- a/mi/miwindow.c
+++ b/mi/miwindow.c
@@ -151,7 +151,7 @@ miMarkOverlappedWindows(WindowPtr pWin, WindowPtr pFirst,
WindowPtr *ppLayerWin)
*/
pChild = pWin;
while (1) {
-if (pChild->viewable) {
+if (pChild->paintable) {
if (RegionBroken(>winSize))
SetWinSize(pChild);
if (RegionBroken(>borderSize))
@@ -175,7 +175,7 @@ miMarkOverlappedWindows(WindowPtr pWin, WindowPtr pFirst,
WindowPtr *ppLayerWin)
box = RegionExtents(>borderSize);
pLast = pChild->parent->lastChild;
while (1) {
-if (pChild->viewable) {
+if (pChild->paintable) {
if (RegionBroken(>winSize))
SetWinSize(pChild);
if (RegionBroken(>borderSize))
@@ -244,7 +244,7 @@ void
miMoveWindow(WindowPtr pWin, int x, int y, WindowPtr pNextSib, VTKind kind)
{
WindowPtr pParent;
-Bool WasViewable = (Bool) (pWin->viewable);
+Bool WasPaintable = pWin->paintable;
short bw;
RegionPtr oldRegion = NULL;
DDXPointRec oldpt;
@@ -261,7 +261,7 @@ miMoveWindow(WindowPtr pWin, int x, int y, WindowPtr
pNextSib, VTKind kind)
oldpt.x = pWin->drawable.x;
oldpt.y = pWin->drawable.y;
-if (WasViewable) {
+if (WasPaintable) {
oldRegion = RegionCreate(NullBox, 1);
RegionCopy(oldRegion, >borderClip);
anyMarked = (*pScreen->MarkOverlappedWindows) (pWin, pWin, );
@@ -280,7 +280,7 @@ miMoveWindow(WindowPtr pWin, int x, int y, WindowPtr
pNextSib, VTKind kind)
ResizeChildrenWinSize(pWin, x - oldpt.x, y - oldpt.y, 0, 0);
-if (WasViewable) {
+if (WasPaintable) {
if (pLayerWin == pWin)
anyMarked |= (*pScreen->MarkOverlappedWindows)
(pWin, windowToValidate, NULL);
@@ -343,7 +343,7 @@ miResizeWindow(WindowPtr pWin, int x, int y, unsigned int
w, unsigned int h,
WindowPtr pSib)
{
WindowPtr pParent;
-Bool WasViewable = (Bool) (pWin->viewable);
+Bool WasPaintable = pWin->paintable;
unsigned short width = pWin->drawable.width, height =
pWin->drawable.height;
short oldx = pWin->drawable.x, oldy = pWin->drawable.y;
int bw = wBorderWidth(pWin);
@@ -373,7 +373,7 @@ miResizeWindow(WindowPtr pWin, int x, int y, unsigned int
w, unsigned int h,
pScreen = pWin->drawable.pScreen;
newx = pParent->drawable.x + x + bw;
newy = pParent->drawable.y + y + bw;
-if (WasViewable) {
+if (WasPaintable) {
anyMarked = FALSE;
/*
* save the visible region of the window
@@ -448,7 +448,7 @@ miResizeWindow(WindowPtr pWin, int x, int y, unsigned int
w, unsigned int h,
pFirstChange = MoveWindowInStack(pWin, pSib);
-if (WasViewable) {
+if (WasPaintable) {
pRegion = RegionCreate(NullBox, 1);
if (pLayerWin == pWin)
@@ -474,7 +474,7 @@ miResizeWindow(WindowPtr pWin, int x, int y, unsigned int
w, unsigned int h,
GravityTranslate(x, y, oldx, oldy, dw, dh, pWin->bitGravity, , );
-if (WasViewable) {
+if (WasPaintable) {
/* avoid the border */
if (HasBorder(pWin)) {
int offx, offy, dx, dy;
@@ -636,13 +636,13 @@ miGetLayerWindow(WindowPtr pWin)
void
miSetShape(WindowPtr pWin, int kind)
{
-Bool WasViewable = (Bool) (pWin->viewable);
+Bool WasPaintable = pWin->paintable;
ScreenPtr pScreen = pWin->drawable.pScreen;
Bool anyMarked = FALSE;
WindowPtr pLayerWin;
if (kind != ShapeInput) {
-if (WasViewable) {
+if (WasPaintable) {
anyMarked = (*pScreen->MarkOverlappedWindows) (pWin, pWin,
);
if (pWin->valdata) {
@@ -663,7 +663,7 @@ miSetShape(WindowPtr pWin, int kind)
ResizeChildrenWinSize(pWin, 0, 0, 0, 0);
-if (WasViewable) {
+if (WasPaintable) {
anyMarked |= (*pScreen->MarkOverlappedWindows) (pWin, pWin, NULL);
if (anyMarked) {
@@ -689,7 +689,7 @@ miChangeBorderWidth(WindowPtr pWin, unsigned int width)
int oldwidth;
Bool anyMarked = FALSE;
ScreenPtr pScreen;
-Bool WasViewable = (Bool) (pWin->viewable);
+Bool WasPaintable = pWin->paintable;
Bool HadBorder;
WindowPtr pLayerWin;
@@ -698,13 +698,13 @@ miChangeBorderWidth(WindowPtr pWin, unsigned int width)
return;
HadBorder = HasBorder(pWin);
pScreen = pWin->drawable.pScreen;
-if (WasViewable && width < oldwidth)
+if (WasPaintable && width < oldwidth)
anyMarked =
[PATCH xserver 6/7] dix: Switch window unmap to mark normally instead of UnmapValData
---
dix/window.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dix/window.c b/dix/window.c
index 55290577d9..34bed93d93 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -2870,7 +2870,7 @@ UnmapWindow(WindowPtr pWin, Bool fromConfigure)
if (SubStrSend(pWin, pParent))
DeliverUnmapNotify(pWin, fromConfigure);
if (wasPaintable && !fromConfigure) {
-pWin->valdata = UnmapValData;
+(*pScreen->MarkWindow) (pWin);
(*pScreen->MarkOverlappedWindows) (pWin, pWin->nextSib, );
(*pScreen->MarkWindow) (pLayerWin->parent);
}
@@ -2920,7 +2920,7 @@ UnmapSubwindows(WindowPtr pWin)
if (parentNotify || StrSend(pChild))
DeliverUnmapNotify(pChild, xFalse);
if (pChild->viewable) {
-pChild->valdata = UnmapValData;
+(*pScreen->MarkWindow) (pChild);
anyMarked = TRUE;
}
pChild->mapped = FALSE;
--
2.17.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 4/7] mi: Shortcut miDoCopy/miCopyArea based on paintable not realized
Signed-off-by: Adam Jackson
---
mi/mibitblt.c | 4 ++--
mi/micopy.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/mi/mibitblt.c b/mi/mibitblt.c
index 2de5bf8fd5..8d70e5494e 100644
--- a/mi/mibitblt.c
+++ b/mi/mibitblt.c
@@ -92,9 +92,9 @@ miCopyArea(DrawablePtr pSrcDrawable,
srcx = xIn + pSrcDrawable->x;
srcy = yIn + pSrcDrawable->y;
-/* If the destination isn't realized, this is easy */
+/* If the destination isn't paintable, this is easy */
if (pDstDrawable->type == DRAWABLE_WINDOW &&
-!((WindowPtr) pDstDrawable)->realized)
+!((WindowPtr) pDstDrawable)->paintable)
return NULL;
/* clip the source */
diff --git a/mi/micopy.c b/mi/micopy.c
index 12cdad4ad5..8fb995a540 100644
--- a/mi/micopy.c
+++ b/mi/micopy.c
@@ -155,7 +155,7 @@ miDoCopy(DrawablePtr pSrcDrawable,
/* Short cut for unmapped windows */
if (pDstDrawable->type == DRAWABLE_WINDOW &&
-!((WindowPtr) pDstDrawable)->realized) {
+!((WindowPtr) pDstDrawable)->paintable) {
return NULL;
}
--
2.17.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 2/7] mi: miValidateTree based on paintable not viewable
Signed-off-by: Adam Jackson
---
mi/mivaltree.c | 108 ++---
1 file changed, 58 insertions(+), 50 deletions(-)
diff --git a/mi/mivaltree.c b/mi/mivaltree.c
index ea6889fdc0..f47cfa4571 100644
--- a/mi/mivaltree.c
+++ b/mi/mivaltree.c
@@ -164,14 +164,16 @@ miShapedWindowIn(RegionPtr universe, RegionPtr bounding,
/*
* Manual redirected windows are treated as transparent; they do not obscure
- * siblings or parent windows
+ * siblings or parent windows. Likewise windows that are paintable but not
+ * mapped.
*/
-#ifdef COMPOSITE
-#define TreatAsTransparent(w) ((w)->redirectDraw == RedirectDrawManual)
-#else
-#define TreatAsTransparent(w) FALSE
-#endif
+static Bool
+TreatAsTransparent(WindowPtr w)
+{
+return (w->redirectDraw == RedirectDrawManual) ||
+(w->paintable && !w->mapped);
+}
#define HasParentRelativeBorder(w) (!(w)->borderIsPixel && \
HasBorder(w) && \
@@ -181,7 +183,7 @@ miShapedWindowIn(RegionPtr universe, RegionPtr bounding,
*---
* miComputeClips --
* Recompute the clipList, borderClip, exposed and borderExposed
- * regions for pParent and its children. Only viewable windows are
+ * regions for pParent and its children. Only paintable windows are
* taken into account.
*
* Results:
@@ -240,37 +242,45 @@ miComputeClips(WindowPtr pParent,
}
#endif
-oldVis = pParent->visibility;
-switch (RegionContainsRect(universe, )) {
-case rgnIN:
-newVis = VisibilityUnobscured;
-break;
-case rgnPART:
-newVis = VisibilityPartiallyObscured;
-{
-RegionPtr pBounding;
+oldVis = newVis = pParent->visibility;
+if (pParent->realized) {
+switch (RegionContainsRect(universe, )) {
+case rgnIN:
+newVis = VisibilityUnobscured;
+break;
+case rgnPART:
+newVis = VisibilityPartiallyObscured;
+{
+RegionPtr pBounding;
-if ((pBounding = wBoundingShape(pParent))) {
-switch (miShapedWindowIn(universe, pBounding,
- ,
- pParent->drawable.x,
- pParent->drawable.y)) {
-case rgnIN:
-newVis = VisibilityUnobscured;
-break;
-case rgnOUT:
-newVis = VisibilityFullyObscured;
-break;
+if ((pBounding = wBoundingShape(pParent))) {
+switch (miShapedWindowIn(universe, pBounding,
+ ,
+ pParent->drawable.x,
+ pParent->drawable.y)) {
+case rgnIN:
+newVis = VisibilityUnobscured;
+break;
+case rgnOUT:
+newVis = VisibilityFullyObscured;
+break;
+}
}
}
+break;
+default:
+newVis = VisibilityFullyObscured;
+break;
}
-break;
-default:
+}
+else if (pParent->paintable)
newVis = VisibilityFullyObscured;
-break;
+else {
+newVis = VisibilityNotViewable;
}
pParent->visibility = newVis;
-if (oldVis != newVis &&
+if (pParent->realized &&
+oldVis != newVis &&
((pParent->
eventMask | wOtherEventMasks(pParent)) & VisibilityChangeMask))
SendVisibilityNotify(pParent);
@@ -293,14 +303,13 @@ miComputeClips(WindowPtr pParent,
(oldVis == VisibilityUnobscured))) {
pChild = pParent;
while (1) {
-if (pChild->viewable) {
+if (pChild->paintable) {
if (pChild->visibility != VisibilityFullyObscured) {
RegionTranslate(>borderClip, dx, dy);
RegionTranslate(>clipList, dx, dy);
pChild->drawable.serialNumber = NEXT_SERIAL_NUMBER;
if (pScreen->ClipNotify)
(*pScreen->ClipNotify) (pChild, dx, dy);
-
}
if (pChild->valdata) {
RegionNull(>valdata->after.borderExposed);
@@ -399,22 +408,22 @@ miComputeClips(WindowPtr pParent,
((pChild->drawable.y == pParent->lastChild->drawable.y) &&
(pChild->drawable.x < pParent->lastChild->drawable.x))) {
for (; pChild; pChild = pChild->nextSib) {
-
[PATCH xserver 1/7] dix: Add 'paintable' bit to the window state (v2)
A paintable window is a window whose pixels are (potentially) modifiable
by rendering commands. Right now that just means the same thing as
viewable; it will soon also include unmapped windows with backing store
set to Always.
v2:
Set paintable in dix not ddx (Keith Packard)
Signed-off-by: Adam Jackson
---
dix/window.c| 5 +
include/windowstr.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/dix/window.c b/dix/window.c
index 8789a5ece5..ea3920c869 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -492,6 +492,7 @@ SetWindowToDefaults(WindowPtr pWin)
pWin->mapped = FALSE; /* off */
pWin->realized = FALSE; /* off */
pWin->viewable = FALSE;
+pWin->paintable = FALSE;
pWin->visibility = VisibilityNotViewable;
pWin->overrideRedirect = FALSE;
pWin->saveUnder = FALSE;
@@ -1056,6 +1057,7 @@ CrushTree(WindowPtr pWin)
FreeResource(pChild->drawable.id, RT_WINDOW);
pSib = pChild->nextSib;
pChild->viewable = FALSE;
+pChild->paintable = FALSE;
if (pChild->realized) {
pChild->realized = FALSE;
(*UnrealizeWindow) (pChild);
@@ -2614,6 +2616,7 @@ RealizeTree(WindowPtr pWin)
if (pChild->mapped) {
pChild->realized = TRUE;
pChild->viewable = (pChild->drawable.class == InputOutput);
+pChild->paintable = (pChild->drawable.class == InputOutput);
(*Realize) (pChild);
if (pChild->firstChild) {
pChild = pChild->firstChild;
@@ -2711,6 +2714,7 @@ MapWindow(WindowPtr pWin, ClientPtr client)
pWin->mapped = TRUE;
pWin->realized = TRUE; /* for roots */
pWin->viewable = pWin->drawable.class == InputOutput;
+pWin->paintable = pWin->drawable.class == InputOutput;
/* We SHOULD check for an error value here XXX */
(*pScreen->RealizeWindow) (pWin);
if (pScreen->ClipNotify)
@@ -2817,6 +2821,7 @@ UnrealizeTree(WindowPtr pWin, Bool fromConfigure)
DeleteWindowFromAnyEvents(pChild, FALSE);
if (pChild->viewable) {
pChild->viewable = FALSE;
+pChild->paintable = FALSE;
(*MarkUnrealizedWindow) (pChild, pWin, fromConfigure);
pChild->drawable.serialNumber = NEXT_SERIAL_NUMBER;
}
diff --git a/include/windowstr.h b/include/windowstr.h
index 4383dabdcf..ae75c96f17 100644
--- a/include/windowstr.h
+++ b/include/windowstr.h
@@ -158,6 +158,7 @@ typedef struct _Window {
unsigned mapped:1;
unsigned realized:1;/* ancestors are all mapped */
unsigned viewable:1;/* realized && InputOutput */
+unsigned paintable:1;
unsigned dontPropagate:3; /* index into DontPropagateMasks */
unsigned forcedBS:1;/* system-supplied backingStore */
unsigned redirectDraw:2;/* COMPOSITE rendering redirect */
--
2.17.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 0/7] Implement backing store's Always mode (version... something)
This is a resend of a series I wrote forever ago and nobody dared review. It probably needs some additional review and rethinking, but it definitely shouldn't keep languishing on my hard drive. The core issue is that Always windows need to have their pixels allocated before the window is ever mapped; some (arguably pathological) applications rely on this to the extent of using the unmapped window as their "offscreen pixmap" and blitting from that to one that's actually mapped. The window tree validation code isn't quite prepared for this, it currently assumes only "viewable" windows need to have valid clip lists (where "viewable" means "InputOutput, is mapped, and all ancestors are mapped"). So this series adds a new "paintable" window state that is effectively "viewable || Always", and adjusts clip list and pixmap management to match. I'm not totally convinced this approach works in combination with overlays (the RGB kind, not the YUV kind); I think mi/mioverlay.c might need to be made similarly aware of Always windows. But if that's the rabbit hole we're going down, I'm not convinced any of ->ValidateTree is factored correctly. I certainly don't like having three mostly-identical copies of it (mi, mioverlay, rootless) nor do I like how xwin/xquartz and xwayland do rootless entirely differently. The mi code certainly has that "optimized for the sun3" smell to it, rewriting it to be comprehensible might be worth whatever performance penalty that incurs. fb/fboverlay.c might work with this approach, but the only driver using that appears to be savage (and in NoAccel mode only! we should delete that) so I might prefer dropping fboverlay in any case. I have some test cases for this that I need to dig out of various archives (and probably a more updated branch somewhere too), and I want to be a bit more sure our tests really are covering this code before merging. Still, any and all feedback appreciated. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
On Mon, 2018-07-23 at 11:23 -0400, Adam Jackson wrote: > Nobody did, so, this is done now. > > My earlier assertion about the git url not being changed is only true > for pulls. For pushes, you will indeed need to update the remote to the > new URL: > > $ git remote set-url origin ssh://g...@gitlab.freedesktop.org/xorg/xserver > > Repo moves will be (early) this week. BZ moves for the more boring > components (protocol, libs, apps, deprecated/abandoned stuff) will > follow shortly thereafter. For detailed migration progress beyond the repo moves, please follow: https://gitlab.freedesktop.org/xorg/meta/issues/1 - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
On Mon, 2018-07-09 at 14:30 -0400, Adam Jackson wrote: > Currently the xorg group in gitlab is derived from the pre-existing > freedesktop LDAP group. This is a bit excessive, there's over 250 > people in the group in total and not even a fifth of those are > regularly active. If you're both a group member and a project member > the highest privilege level is used; currently, this would mean all of > these accounts are maintainers for every project. > > That's not _different_ from the current state of affairs, but since we > now have the easy ability to delegate access control per-project, we > should take the opportunity to prune the list of xorg group > members. These accounts will still exist in gitlab, and if the > contributor returns they are welcome to rejoin. As a totally arbitrary > cutoff I'd suggest pruning anyone who hasn't had an Author or Commit > credit in git in the last, say, three years. > > If you want a differently arbitrary cutoff, or have other feedback, > please speak up. Nobody did, so, this is done now. My earlier assertion about the git url not being changed is only true for pulls. For pushes, you will indeed need to update the remote to the new URL: $ git remote set-url origin ssh://g...@gitlab.freedesktop.org/xorg/xserver Repo moves will be (early) this week. BZ moves for the more boring components (protocol, libs, apps, deprecated/abandoned stuff) will follow shortly thereafter. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] modesetting: Fix 16 bit depth/bpp mode
On Mon, 2017-01-02 at 14:42 -0500, Adam Jackson wrote:
> On Thu, 2016-12-22 at 15:41 +0100, Stefan Agner wrote:
> > When setting DefaultDepth to 16 in the Screen section, the current
> > code requests a 32 bpp framebuffer, however the X-Server seems to
> > assumes 16 bpp.
> >
> > Fixes commit 21217d02168d ("modesetting: Implement 32->24 bpp
> > conversion in shadow update")
> >
> > Signed-off-by: Stefan Agner
> > ---
> > Observed this issue using X-Server/modesetting 1.18.4 and the FSL
> > DCU DRM driver, but I am pretty sure it is driver independent. Not
> > sure if the change is properly taking care of the corner case which
> > was initially targetted, but it makes specifiying DefaultDepth with
> > values of 16/24/32 and not specifiying it work for me.
>
> Without this patch, what path do you end up taking through
> drmmode_get_default_bpp() ? I'm a little suspicious of the error
> handling in that function.
Enh, not worth caring that much. This is correct, merged:
remote: remote: I: patch #129230 updated using rev
1c7f34e99ff9750979a03ae20c6be1f2b42c284c.
remote: remote: I: 1 patch(es) updated to state Accepted.
remote: To ssh://kemper.freedesktop.org/git/xorg/xserver
remote:d95a1310e..1c7f34e99 1c7f34e99ff9750979a03ae20c6be1f2b42c284c ->
master
To ssh://gitlab.freedesktop.org/xorg/xserver
d95a1310ef..1c7f34e99f master -> master
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration (including account update plans, please read)
On Mon, 2018-07-02 at 10:23 -0700, Keith Packard wrote: > For the first step, I'd like to propose moving the x server git > repository to gitlab in the coming week, with the switch-over happening > on the morning of July 9. This is now done: https://gitlab.freedesktop.org/xorg/xserver The old git URLs still work, so this change should be transparent for existing checkouts. We'll be moving more repositories over the coming weeks. Currently the xorg group in gitlab is derived from the pre-existing freedesktop LDAP group. This is a bit excessive, there's over 250 people in the group in total and not even a fifth of those are regularly active. If you're both a group member and a project member the highest privilege level is used; currently, this would mean all of these accounts are maintainers for every project. That's not _different_ from the current state of affairs, but since we now have the easy ability to delegate access control per-project, we should take the opportunity to prune the list of xorg group members. These accounts will still exist in gitlab, and if the contributor returns they are welcome to rejoin. As a totally arbitrary cutoff I'd suggest pruning anyone who hasn't had an Author or Commit credit in git in the last, say, three years. If you want a differently arbitrary cutoff, or have other feedback, please speak up. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] meson: ensure the libc has RPC functions when secure-rpc is enabled
On Fri, 2018-06-22 at 12:49 -0400, Lyude Paul wrote: > Currently our meson.build just makes the assumption that the libc is > going to provide RPC functions. This doesn't actually seem to be the > case on Fedora, which causes compilation to fail unexpectedly: > > ../../Projects/xserver/os/rpcauth.c:47:10: fatal error: rpc/rpc.h: No such > file or directory > #include > ^~~ > compilation terminated. > > So, in the event that we can't use libtirpc ensure that we actually > check whether or not the libc provides rpc/rpc.h. If it doesn't, raise > an error. > > Signed-off-by: Lyude Paul Merged, thanks: remote: I: patch #231304 updated using rev d95a1310ef8e08a93a28f9766d1b4093f7891404. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver d83efc47b7..d95a1310ef master -> master - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] xf86-video-modesetting: Lease planes as well if using atomic
On Wed, 2018-06-27 at 10:41 +0100, Daniel Stone wrote: > Hi, > > On Wed, 27 Jun 2018 at 00:35, Keith Packard wrote: > > @@ -3251,6 +3251,9 @@ drmmode_create_lease(RRLeasePtr lease, int *fd) > > > > nobjects = ncrtc + noutput; > > > > +if (ms->atomic_modeset) > > +nobjects += ncrtc; > > This seems like it definitely wants a comment as to why we add ncrtc > twice (for the primary plane). But, with that (and no need to pass it > through the list again): > Reviewed-by: Daniel Stone Added such comment, and merged the series: remote: I: patch #232471 updated using rev 4a11f66e4690f9e94dc61cb264f5ef78dbdb255a. remote: E: failed to find patch for rev d83efc47b7a524b4f8d4a993c27a3e402a98fa7c. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 2faf4cef8b..d83efc47b7 master -> master - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 2/2] xfree86: Wrap RRCrtcIsLeased and RROutputIsLeased to check for DIX structures
On Thu, 2018-06-28 at 11:45 -0700, Keith Packard wrote: > Before DIX structures are allocated for crtcs and outputs, we don't > want to call DIX randr code with NULL pointers. This can happen if the > driver sets video modes early in server initialization, which Nouveau > does in zaphod mode. > > Cc: thellst...@vmware.com > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106772 > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=106960 > Signed-off-by: Keith Packard Merged the series, thanks: remote: I: patch #233515 updated using rev c55a44a9a86aaece17c1a2e73c77e3e665c4888e. remote: I: patch #226987 updated using rev 2faf4cef8bcf9bb2034a27219a656ea7221afc6c. remote: I: 2 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 49283e238a..2faf4cef8b master -> master - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On Mon, 2018-07-02 at 10:23 -0700, Keith Packard wrote: > Adam Jackson writes: > > > I'd like us to start moving repos and bug tracking into gitlab. > > I would also like to get to a merge-request model at some > point. However, I think we can take this in stages and start by moving > the git repos over to gitlab, and then move the bugs over, and finally > start doing patch review via the gitlab issue tracker. > > For the first step, I'd like to propose moving the x server git > repository to gitlab in the coming week, with the switch-over happening > on the morning of July 9. I don't really see a reason not to move the repos for everything. It's a pretty invisible change since the old URLs keep working, and I'm itchy to see CI wired up. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] meson: Add configuration of listening on tcp, unix and local
On Fri, 2018-06-29 at 09:44 +0200, Laurent Carlier wrote: > You've forgotten the gitlab repo I have a (non-automatic) personal mirror on gitlab, but we've not properly moved yet. If you're interested in following that progress, see: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40 - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
