Giuseppe Bilotta writes:
> - 2 CARD16 ncrtcs
> + 2 CARD16 noutputs
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
Giuseppe Bilotta writes:
> Not in the sense I mean above. If the string is a sequences of
> whitespace characters, strtod would return 0 as value (no conversion),
> and set endptr to the end of the string, because it would gobble the
> whitespace. This would be
Giuseppe Bilotta writes:
> While I find this conceptually acceptable, I have an uneasy feeling
> about its practicality.
Yeah, we'd definitely have to experiment with both X server and
Compositing Manager changes together to see what actually works.
> I'm coming at
Giuseppe Bilotta writes:
> Maybe we don't even need to change the AutoList. What we want is to
> ensure that the Compositing Manager has _processed_ the notification
> of the geometry change for the windows in the AutoList. This could be
> achieved for exampe by
---
randrproto.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/randrproto.txt b/randrproto.txt
index c06bc90..f57301d 100644
--- a/randrproto.txt
+++ b/randrproto.txt
@@ -2363,14 +2363,14 @@ A.1.1 Common Types added in version 1.5 of the protocol
4 ATOM
On Tue, Feb 6, 2018 at 1:01 AM, Keith Packard wrote:
> Giuseppe Bilotta writes:
>
>> I'm not a big fan of strtod because with it it's impossible to know if
>> a conversion actually happened. xrandr --scale ' ' would actually be
>> accepted
On Mon, Feb 5, 2018 at 9:24 PM, Keith Packard wrote:
> What we want is for the compositing manager to get a clean snapshot of
> the system and to then be able to present that on the screen each
> frame. That means disallowing *all* changes for the duration of the
> construction
Giuseppe Bilotta writes:
> I'm not a big fan of strtod because with it it's impossible to know if
> a conversion actually happened. xrandr --scale ' ' would actually be
> accepted (resulting in a scale value of 0), while the scanf catches
> it.
strtod takes an
Adam Jackson writes:
> On Mon, 2018-02-05 at 12:39 -0800, Keith Packard wrote:
>
>> randrproto.pc.in| 2 +-
>
> Please be sure to bump the pc version in meson.build too. (If there's a
> more convenient way to only bump things once, great, let's do that
>
Unfortunately, on my machine Xwayland immediately crashes when I try to
start it. gdb backtrace:
#0 0x774f0e79 in wl_proxy_marshal () from
target:/lib64/libwayland-client.so.0
#1 0x00413172 in zwp_confined_pointer_v1_destroy
(zwp_confined_pointer_v1=0x7)
at
On Mon, 2018-02-05 at 15:24 -0500, Adam Jackson wrote:
> I've asked this a couple of times on IRC, repeating it here for wider
> distribution. I had thought I had a git import laying around somewhere
> but I can't seem to find it. cvs.xfree86.org hasn't been alive in a
> long time, and it'd be a
On Mon, 2018-02-05 at 12:39 -0800, Keith Packard wrote:
> randrproto.pc.in| 2 +-
Please be sure to bump the pc version in meson.build too. (If there's a
more convenient way to only bump things once, great, let's do that
instead.)
> +7.6. Extension Requests added in version
On Sun, 2018-02-04 at 23:17 -0600, Jeff Smith wrote:
> DoConfigure() attempts to call the PreInit handler on a device without
> checking that the handler exists.
>
> Check that the PreInit handler exists for a device before attempting to
> call it.
This is a bit strange to me as the PreInit hook
I've just taken my randrproto patches and cherry-picked them into
xorgproto, then cleaned up the bits for the randrproto version number.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info:
non-desktop devices are those to which the normal desktop environment
should not be extended. Examples are Head-mounted displays and the
Apple Touch Bar.
How an output device is set to non-desktop is not part of this
proposal; it is expected that the underlying operating system will
provide this
A "lease" is a set of crtc and output resources granted to another
application for use outside of X. These will not be usable through the
X protocol until the lease terminates. Leased outputs will be seen as
disconnected, leased CRTCs will be seen as not usable with any output.
v2:
Delete
Giuseppe Bilotta writes:
> So the only difference between the two approaches is that in the
> current async way the server can cover the latency that would come
> from waiting for the WM to complete the mapping (or in general other
> such requests) by processing other
I've asked this a couple of times on IRC, repeating it here for wider
distribution. I had thought I had a git import laying around somewhere
but I can't seem to find it. cvs.xfree86.org hasn't been alive in a
long time, and it'd be a shame if that history just got lost,
fragmentary as it was. If
On Mon, 2018-02-05 at 12:53 +0100, Michel Dänzer wrote:
> > > The inability to queue a presentation to the next MSC is more of a step
> > > back compared to the status quo.
> >
> > I'm about to go write up some ideas I'm working on that will make it
> > possible to more regularly display
The big change here is MakeCurrent and context tag tracking. We now
delegate context tags entirely to the vnd layer, and simply store a
pointer to the context state as the tag data. If a context is deleted
while it's current, we allocate a fake ID for the context and move the
context state there,
On Mon, 2018-02-05 at 12:05 -0700, Kyle Brenneman wrote:
> In __glXDisp_DestroyContext, doesn't it need to record the fake XID that
> it generates? If I'm reading it right, if the client deletes a current
> context and later unbinds it, then xorgGlxMakeCurrent will call
> FreeResourceByType
On 02/ 5/18 11:06 AM, Adam Jackson wrote:
> On Mon, 2018-02-05 at 10:38 -0500, Adam Jackson wrote:
>> Would anyone have a problem with only making xz tarballs?
>
> This would still be nice to know the answer to.
I wouldn't, since we deal with those for GNOME already.
--
-Alan
On Sat, Feb 03, 2018 at 02:28:58PM -0800, Keith Packard wrote:
> Adam Jackson writes:
>
> > Got impatient and hacked on this a bit more:
> >
> > https://cgit.freedesktop.org/xorg/proto/xorgproto/
>
> Thanks for taking this on. It looks great.
>
> I have a question -- is there
Michel Dänzer writes:
> The motivation for this work is fullscreen applications with Xwayland.
I think this could be equally useful for windowed applications as well
as it should allow them to avoid the copy to the window pixmap and
(perhaps) land in an overlay in whatever
Michel Dänzer writes:
> Ignoring the Security extension, the client has the same control over
> the contents of another application's window *using* the X protocol,
> doesn't it?
Yeah, good point -- it could easily call DRI3BufferFromPixmap for the
window pixmap and have
On Mon, 2018-02-05 at 10:38 -0500, Adam Jackson wrote:
> Now, can we call the meson build official and do the releases from
> that, probably yes with some more work.
Update: "some more work" is turning out to be more than I want to spend
on this at the moment. release.sh's use of git worktrees
On 02/02/2018 12:15 PM, Adam Jackson wrote:
The big change here is MakeCurrent and context tag tracking. We now
delegate context tags entirely to the vnd layer, and simply store a
pointer to the context state as the tag data. If a context is deleted
while it's current, we allocate a fake ID for
On Sat, 2018-02-03 at 14:28 -0800, Keith Packard wrote:
> Adam Jackson writes:
>
> > Got impatient and hacked on this a bit more:
> >
> > https://cgit.freedesktop.org/xorg/proto/xorgproto/
>
> Thanks for taking this on. It looks great.
>
> I have a question -- is there any
On 2018-02-02 11:11 PM, Keith Packard wrote:
> Michel Dänzer writes:
>
>> But this seems irrelevant for per-window flips. In this case, the window
>> pixmap isn't used for anything else after flipping, so having direct
>> access to the pixmap doesn't allow the client to do
On 2018-02-02 09:56 PM, Keith Packard wrote:
> Michel Dänzer writes:
>
>> On 2018-02-02 10:42 AM, Roman Gilg wrote:
>>> It's because of what you made me aware of in the previous patch set:
>>> the window original pixmap needs to have the updated content from the
>>> flip
Am 05.02.2018 11:24, schrieb Giuseppe Bilotta:
> On Mon, Feb 5, 2018 at 10:44 AM, walter harms wrote:
>>
>> Am 05.02.2018 02:47, schrieb Giuseppe Bilotta:
>>> {
>>> double sx, sy;
>>> + char junk;
>>> if (!config_output) argerr ("%s must be used
On 02/05/2018 11:20 AM, Mario Kleiner wrote:
Commit 91c42093b248 ("glx: Duplicate relevant fbconfigs for
compositing visuals") adds many new depth 32 fbconfigs as
composite visuals. On a X-Screen running at depth 24, this
also adds bgra 10-10-10-2 fbconigs, as they also have
config.rgbBits ==
On Mon, Feb 5, 2018 at 10:44 AM, walter harms wrote:
>
> Am 05.02.2018 02:47, schrieb Giuseppe Bilotta:
>> {
>> double sx, sy;
>> + char junk;
>> if (!config_output) argerr ("%s must be used after --output\n",
>> argv[i]);
>> if (++i >=
Commit 91c42093b248 ("glx: Duplicate relevant fbconfigs for
compositing visuals") adds many new depth 32 fbconfigs as
composite visuals. On a X-Screen running at depth 24, this
also adds bgra 10-10-10-2 fbconigs, as they also have
config.rgbBits == 32, but these are not displayable on a
depth 24
Am 05.02.2018 02:47, schrieb Giuseppe Bilotta:
> We used to accept something like --scale 2x3junk as a valid input
> (scaling x by 2 and y by 3), even though this isn't really a valid
> scaling factor.
>
> Fix by making sure there is nothing after the parsed number(s).
>
> Signed-off-by:
On Mon, Feb 5, 2018 at 4:27 AM, Keith Packard wrote:
> Giuseppe Bilotta writes:
>
>> I'm not sure if this could be implemented without making the server
>> more susceptible to DOS attacks, though (basically the same issue I
>> see in the blocking
Hi,
* Keith Packard [180203 20:33]:
> Tony Lindgren writes:
>
> > Looks like drmModeDirtyFB() stopped working at some point and we now
> > call it with fb_id of zero for rotated displays. This will stop displays
> > relying on DRM_IOCTL_MODE_DIRTYFB ioctl
Looks like drmModeDirtyFB() stopped working at some point and we now
call it with fb_id of zero for rotated displays. This will stop displays
relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.
This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
support for using RandR
38 matches
Mail list logo