DBE incompatible with Xrender?
I can't seem to draw to a Picture corresponding to a back buffer created by the double buffer extension; when I swap the window with XdbeCopied it becomes apparent that no drawing has actually occured, but no error is generated either, and it works fine if I create the picture for the window and not the back buffer (and avoid swapping buffers, of course). The picture format I'm using to create the picture is the picture format returned by XRenderFindVisualFormat for the same visual that created the window the back buffer was allocated for. I must be missing something here. Any ideas? Thanks in advance.
Wayland compatibility layer
Over the past several months, I and some other individuals wrote a Wayland compositor that runs on common X setups. The code can be found here: https://sourceforge.net/projects/twelveto11/ It should be a more or less complete implementation of the important parts of the Wayland protocol. Buffer transforms are currently missing, but that's because I can't wrap my head around how they work. If DRI3 is extended to allow creating Xv video, it would allow implementing YUV image formats without a dependency on GL. The only major inefficiency I can think of is that buffer contents get copied at least once, to the offscreen storage of the toplevel window, which is then composited by the X compositing manager. Buffer-flipping does not yet work well for fullscreen opaque surfaces, as that requires some additions to the Composite extension here to work well: https://lists.x.org/pipermail/xorg-devel/2022-October/058918.html Please try it out and report any crashes or bugs that you may come across. Thanks in advance. Patches are also welcome, and the code should be well commented and structured, but please keep in mind the coding standards (which happen to overlap greatly with the GNU ones): https://www.gnu.org/prep/standards.
Re: Wayland compatibility layer
Lyude Paul writes: > Hi, I saw this and had a couple questions. When you say "wayland compatibility > layer" I assumed at first this was for some reason a duplicate of nested > compositors but I think I may have misunderstood. Is this basically the > opposite of Xwayland, e.g. allowing X to act as a wayland compositor with > twelveto11 as the translation layer? Yes. It doesn't provide any window management functionality itself, instead leaving that to the X window manager. > Also JFYI - seeing as this is a freedesktop/x.org adjacent project you're more > then welcome to use our gitlab instance if you'd like something a bit more > accessible to host your code on. Thanks for the offer, but I'd rather keep it on SourceForge for now.
Re: Slow rendering when GC.line_style = LineOnOffDash
"Farrington, Paul" writes: > We’ve noticed that XDrawRectangle where the GC.line_style is > LineOnOffDash has gotten slower in recent X Server releases. We’ve > observed this on both Linux RH8 and FBSD 11.4 and above. There are two > sample programs pasted below, one which draws 5 rectangles with > LineSolid and one which draws 5 rectangles with LineOnOffDash. There > is also a makefile for RH8. Running the two programs with an X Server > version 1.18.4, both programs render the rectangles instantly. But in > X Server version 1.20.8 or more obviously 1.20.14, rendering the > dashed line rectangles is much slower. You can watch them being drawn > on the screen, whereas the solid line version still renders instantly. This information doesn't help unless you tell us: - which graphics driver (xf86-video-foo) you are using. - what kind of acceleration it is using (i.e. EXA, UXA, SNA, or Glamor.)
Re: XGrabButton
Riza Dindir writes: > Since the XGrabPointer call with AnyButton and AnyModifier does grab > for all modifiers and buttons, how should I make it propagate to the > window the button press event (without modifiers). I tried XSendEvent > to send the button press event to that window, but it did not respond. > The application does not operate as expected. > > It is perfectly ok for me to use 3 XGrabButton calls, but was > wondering why this would not work for a XGrabButton call with > AnyButton and AnyModifier parameters. The application in question might be using the X input extension and only responding to XI events, and you likely forgot to change the event window contained in the event before resending it to the application. It's generally a bad idea to intercept and ``resend'' events to other X clients, as you are required to translate the event coordinates yourself, and the recipients will see events arrive with their timestamps out-of-order. Additionally, you will have to translate input extension events generated by both versions of the extension, and any generated by extensions that haven't yet been invented.
Re: Xlib: DisplayWidth / DisplayHeight
Zbigniew writes: > Hello, > > I believe there's a need to change the functionality of the > DisplayWidth and DisplayHeight functions. > > It has nowadays become quite common to use the so-called virtual > screens — i.e. providing a larger operating field than visible on the > screen. The problem is that when using a virtual screen, both > functions mentioned return its size and not size of the physical > screen, which seldom makes sense in programming practice (for example, > see: > https://stackoverflow.com/questions/28774830/retrieve-physical-screen-size > > https://unix.stackexchange.com/questions/573121/get-current-screen-dimensions-via-xlib-using-c > ). Are you making reference to DisplayWidth and DisplayHeight, or DisplayWidthMM and DisplayHeightMM? And please explain which X extension supplies your ``virtual screen'' functionality; I daresay the ``screens'' you speak of are not true screens in the X sense, but rather monitors or outputs, wherein the server extension that implements them should be exploited to ascertain their dimensions.
Re: Xlib: DisplayWidth / DisplayHeight
Zbigniew writes: >> Are you making reference to DisplayWidth and DisplayHeight, or >> DisplayWidthMM and DisplayHeightMM? > > Talking about DisplayWidth and DisplayHeight functions. > >> And please explain which X extension supplies your ``virtual >> screen'' functionality > > It's done like this: > xrandr --output DVI-0 --mode 1920x1200 --panning 2520x1575 > >> rather monitors or outputs, wherein the server extension that >> implements them >> should be exploited to ascertain their dimensions. > > No, there are two functions, that should return the proper values > regardless of how the virtual screen was created, which extension has > been used etc. The programmer shouldn't be bothered with such kind of > investigation. > And I'm not talking about size of virtual screen ˛— you may want to > read again my initial post — but exactly about „physical screen” > dimensions. These are the values that should be returned by > DisplayWidth and DisplayHeight functions. > > So I would expect (in my particular case) to get 1920 and 1200 values, > and NOT dimensions of virtual screen, I mean 2520 and 1575 The behavior prescribed for these macros is to return the width and height of the screen, and doesn't provide for the existence of concepts such as panning or Xinerama. Furthermore, any change to their existing semantics would cause countless programs reliant on its present behavior to malfunction. Use the XRandR extension to ascertain the dimensions of individual outputs: an X "screen" designates a single root window, not a physical output device, and its dimensions therefore do not reflect that of any outputs which may be connected. As one of the cornerstones of the X protocol, it cannot be subject to change.
Re: Xlib: DisplayWidth / DisplayHeight
Zbigniew writes: > No, dear Volodya, > >„The DisplayHeight macro returns the height of the specified screen > in >pixels. > >The DisplayWidth macro returns the width of the screen in pixels.” > > This is what I want, and this is what — as „man” page states — I > should get, regardless of presence of any „subsystems”. I want nothing > more than is described there. And it is what you do receive, only that the dimensions of the screen are not what you _want_. > Are you serious when stating, that during creation of a program I > should play guessing game „what kind of 'subsystem' the user may > employ”? Or you could ask the server to provide a list of extensions in use. It's one of the realities of X development. Deal with it.
Re: Xlib: DisplayWidth / DisplayHeight
Zbigniew writes: > You already know, what I mean — since you've already guessed it: the > physical screen I have. Why? Because that's the area where the window > of my program will appear. > What makes you think, that the creators of these functions, when > designing them years ago, meant anything different at that time, than > „resolution of physical screen handled by its Xserver”? They were not designed ``years ago'', but decades ago, and without stipulating the nature or number of output devices connected to each screen, but merely its function as an identifier for a root window and graphics configuration. Client windows must be inferiors of the root window, and the root window spans the entirety of its screen, so by necessity any extension that connects multiple outputs to the same ``desktop'' (root window) must connect multiple outputs to the same screen.
Re: Information on xkb group index in bits 13 & 14 of event state information for input events
Farblos writes: > Hi Xorg, > > in this FVWM issue: > > https://github.com/fvwmorg/fvwm3/issues/861 > > bits 13 and 14 encoding the XKB group index in event->xkey.state > on behalf of the XKB extension interfere with FVWM's modifier > handling. > > At least that is what I have understood so far from my tests and > > > https://www.x.org/releases/X11R7.6/doc/libX11/specs/XKB/xkblib.html#xkb_state_to_core_protocol_state_transformation > > Is there anything better than just masking out bits 13 and 14 in > event->xkey.state as I have proposed as solution for that issue? > Is there some constant that represents these two bits? No, the solution is to remove those two bits. This has no negative consequences, but make sure the bits are restored before the event's modifier mask is provided to a keycode or keysym translation function.
Re: Xlib: DisplayWidth / DisplayHeight
Zbigniew writes: > I've got a feeling you are trying to dilute this exchange by > artificially introducing conceptual confusion. Sure, the distinction between screens and output devices may be confusing. But it is how X functions, and is not subject to change, particularly not merely to congrue with your opinion of how it should. So deal with it. Here is some code you can refer to: https://git.savannah.gnu.org/cgit/emacs.git/tree/src/xfns.c#n6254
