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 no
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. Buff
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 a
"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
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
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 proble
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 thi
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
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 anythin
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
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
11 matches
Mail list logo
