Re: Fw: merging imake fork

[Keith Packard]

Alan Coopersmith  writes:

> and the most likely outcome will be many people recommending you move
> to anything but Imake, and maybe offering to make you the maintainer of 
> X.Org's
> version so we can stop paying attention to it too.

I don't think we even want imake in the X.org repository anymore. I'd
suggest that the CDE developers are likely the best candidates to own
that project at this point, unless they decide to switch to something
more modern as we have.

-- 
-keith


signature.asc
Description: PGP signature
___
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: Fw: merging imake fork

[Alan Coopersmith]

On June 19, 2018 9:45 PM, Chase  wrote:



Hello,
I am part of the open source group continuing to develop CDE, the common 
desktop environment. We have been attempting to package CDE for debian for 
quite some time now, and have been hitting a couple of snags. The one that has 
made me contact you is that we currently maintain our own fork of imake, due 
to the fact that we have had to bootstrap our own imake to compile properly, 
but we have very little desire to continue with the fork of imake, and would 
like to merge with upstream. If you guys have the time, would you mind taking 
a look at our code and seeing what you can merge in from our forks of imake, 
makepend and the xorg config files? This would be extremely helpful as we 
eventually want to simply depend on the xutils package. Also, if it's not a 
big burden, we have a mailing list that would be helpful so that we could 
collaborate and work on imake together (as we do have people supporting imake, 
we just want upstream to have the changes as well) the list is 
cdesktopenv-de...@lists.sourceforge.net


Sorry, but I have zero time available to go look at other Imake implementations
for the foreseeable future.  I've cc'ed the X.Org developers list to see if
anyone else has time to help, but really, no one wants to maintain any Imake
code now, and the most likely outcome will be many people recommending you move
to anything but Imake, and maybe offering to make you the maintainer of X.Org's
version so we can stop paying attention to it too.

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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: A question about XCompositeRedirectSubwindows

[Jasper St. Pierre]

On Tue, Jun 19, 2018 at 2:23 PM Egil Möller 
wrote:

> Oups, sorry for my reply-to-you-only, that was a mistake.
>
> So my problem with letting events "fall through" to the window is that I
> plan to do zoom (hence the OpenGL), both in and out, and would like to have
> events working even in a zoomed state... The window manager idea I'd like
> to build is one that extends the multiple virtual workspaces metaphor into
> an infinite desktop that you can zoom and pan as you like, and paste a
> window onto at any size at any zoom level... It might be a bit hard as a
> first project this deep into X stuff, but it's something I've wanted to
> build for a long while. So, what are the reasons synthesizing events will
> fail (and how will they fail)?
>

First off, there's a super high latency cost here. Second, actually filling
in the correct event is unobvious and tricky, especially when dealing with
XInput2. It would require building the equivalent of an X server inside
your CM to send. It would probably not be too much work for anything that
doesn't use too many server-side subwindows and just treats the window as a
single surface, so it mght be good enough for most cases, but I'd be
sketchy. And most apps that don't use server-side windows will be the ones
using XI2. Third, input grabs will override your COW, so anything that uses
a pointer grab will see bizarre behavior. Fourth, synthesized events are
specially marked, and some clients might throw out events with the
synthesized flag set.

To be honest, this problem was one of the original problems that Wayland
tried to solve. In the Wayland architecture, the display server and
compositing manager are combined into a single process, and the compositor
has full control over sending events to surfaces. It might be easier to
hack up a Wayland compositor to get it to do what you want.


> Hehe, that is the impression I got from plowing through the specs and code
> too.. It would kind of be useful to get to talk to one of those people
> about how things are "supposed to work".
>

A lot of those people are on this list. Or, if not here, on the
wayland-devel list. I'm not one of them, but I feel I've worked on enough
X-related things to understand how the system is put together.


> Thanks! I think I might need it :P
>
>
> On 19. juni 2018 16:52, Jasper St. Pierre wrote:
>
> Hi,
>
> (Re-adding xorg-devel. Please make sure to keep the list CC'd in the
> future)
>
> It is possible for a window to set "no background color", in which case
> the existing window contents are used for the pixmap. xclock likely sets no
> background color. You can check an individual window's properties with
> xwininfo.
>
> Redrawing the screen every frame isn't a bad idea for a simple compositor
> to get started. For a more fancy, complete redraw loop, you can track when
> windows get drawn to with with the Damage extension, and schedule a repaint
> when that happens. Bonus points if you use the damage rectangles to be more
> accurate with your redraw. Also, helpful hint that windows get their
> backing pixmaps thrown away when resized -- you need to pay attention to
> ConfigureNotify and regrab the backing pixmap with
> XCompositeNameWindowPixmap, and that whole jazz.
>
> I don't recommend synthesizing input events -- a lot of things are likely
> to break or just not work well. Set an empty input shape on the COW, and
> make sure to draw windows where they want to be. Pay attention to
> MotionNotify events from windows that are moving.
>
> I'm unaware of any beginner-level documentation or tutorials. The number
> of people that have written a compositing manager from scratch can be
> counted on one hand, and a lot of them had a hand in designing the
> architecture to begin with.
> https://magcius.github.io/xplain/article/composite.html has some ideas of
> the broader concepts, but none of the details.
>
> Good luck.
>
> On Tue, Jun 19, 2018 at 2:01 AM Egil Möller 
> wrote:
>
>> Hi!
>>
>> Thanks for answering a noob question :) Ha! That's so not documented (in
>> an obvious way)! I was assuming that I could get the initial window
>> content, as already drawn (obviously clipped to whatever is visible on
>> screen) directly... So why does xclock "work" then? I just haven't gotten
>> around to event handling yet, wanted to learn the drawing/copying methods
>> themselves first...
>>
>> Two follow up questions:
>>
>>   * How should I redraw the screen? As often as I can, or waiting for
>> some event for all redirected windows (which event)?
>>   * Can I capture input events (key, mouse) for the overlay window and
>> then somehow synthesize them for whatever window / subwindow my window
>> manager thinks it has drawn in that position? Some docs I read sounded like
>> this is impossible, and you should turn of input for the overlay, and
>> position the real window underneath in a "strategic position"...
>>
>> Also, is there any good documentation and/or tutorials around this
>> anywhere?
>>
>> 

Re: A question about XCompositeRedirectSubwindows

[Egil Möller]

Oups, sorry for my reply-to-you-only, that was a mistake.

So my problem with letting events "fall through" to the window is that I
plan to do zoom (hence the OpenGL), both in and out, and would like to
have events working even in a zoomed state... The window manager idea
I'd like to build is one that extends the multiple virtual workspaces
metaphor into an infinite desktop that you can zoom and pan as you like,
and paste a window onto at any size at any zoom level... It might be a
bit hard as a first project this deep into X stuff, but it's something
I've wanted to build for a long while. So, what are the reasons
synthesizing events will fail (and how will they fail)?

Hehe, that is the impression I got from plowing through the specs and
code too.. It would kind of be useful to get to talk to one of those
people about how things are "supposed to work".

Thanks! I think I might need it :P


On 19. juni 2018 16:52, Jasper St. Pierre wrote:
> Hi,
>
> (Re-adding xorg-devel. Please make sure to keep the list CC'd in the
> future)
>
> It is possible for a window to set "no background color", in which
> case the existing window contents are used for the pixmap. xclock
> likely sets no background color. You can check an individual window's
> properties with xwininfo.
>
> Redrawing the screen every frame isn't a bad idea for a simple
> compositor to get started. For a more fancy, complete redraw loop, you
> can track when windows get drawn to with with the Damage extension,
> and schedule a repaint when that happens. Bonus points if you use the
> damage rectangles to be more accurate with your redraw. Also, helpful
> hint that windows get their backing pixmaps thrown away when resized
> -- you need to pay attention to ConfigureNotify and regrab the backing
> pixmap with XCompositeNameWindowPixmap, and that whole jazz.
>
> I don't recommend synthesizing input events -- a lot of things are
> likely to break or just not work well. Set an empty input shape on the
> COW, and make sure to draw windows where they want to be. Pay
> attention to MotionNotify events from windows that are moving.
>
> I'm unaware of any beginner-level documentation or tutorials. The
> number of people that have written a compositing manager from scratch
> can be counted on one hand, and a lot of them had a hand in designing
> the architecture to begin with.
> https://magcius.github.io/xplain/article/composite.html has some ideas
> of the broader concepts, but none of the details.
>
> Good luck.
>
> On Tue, Jun 19, 2018 at 2:01 AM Egil Möller  > wrote:
>
> Hi!
>
> Thanks for answering a noob question :) Ha! That's so not
> documented (in an obvious way)! I was assuming that I could get
> the initial window content, as already drawn (obviously clipped to
> whatever is visible on screen) directly... So why does xclock
> "work" then? I just haven't gotten around to event handling yet,
> wanted to learn the drawing/copying methods themselves first...
>
> Two follow up questions:
>
>   * How should I redraw the screen? As often as I can, or waiting
> for some event for all redirected windows (which event)?
>   * Can I capture input events (key, mouse) for the overlay window
> and then somehow synthesize them for whatever window / subwindow
> my window manager thinks it has drawn in that position? Some docs
> I read sounded like this is impossible, and you should turn of
> input for the overlay, and position the real window underneath in
> a "strategic position"...
>
> Also, is there any good documentation and/or tutorials around this
> anywhere?
>
> /Egil
>
> On 19. juni 2018 08:42, Jasper St. Pierre wrote:
>> Hi,
>>
>> What you're seeing here is a fun little side effect of composite.
>> As you might be aware, unredirected X windows don't have any
>> backing storage beyond the front buffer -- the full window
>> contents are not really there. That means that when the X server
>> first goes to redirect these windows, it decides that it should
>> let the window paint again, and sends the window an Expose event
>> to let it know it should repaint. A side effect of this is that
>> the X server redraws the background for the window. This is the
>> semantics for what an Expose event means -- an area that is
>> "Exposed" is the background color until the client paints over it.
>>
>> The client will eventually paint its window contents, but since
>> your CM does not appear to have a frame loop, and it only paints
>> once, you do not see the updated frame contents.
>>
>> On Sun, Jun 17, 2018 at 1:28 PM Egil Möller
>> mailto:e...@innovationgarage.no>> wrote:
>>
>> Hi!
>>
>> I'm trying to write a new compositing window manager, and
>> finding the
>> documentation for the API:s I need quite spread out.
>>
>> The particular problem I'm having right 

Re: [PATCH xserver] : bug 106963 : change the DPMS initialization to be conditional on not set from config

[John Lumby]

Any DPMS timeout values set in ServerFlags section of the xorg.conf are being 
overwritten
 by DPMS extension initialization. 
Therefore change the DPMS initialization of timeout values to be conditional on 
not set from config.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106963

diff --git a/xorg/xserver/Xext/dpms.c.orig b/xorg/xserver/Xext/dpms.c
index efa7154..e43a379 100644
--- a/xorg/xserver/Xext/dpms.c.orig
+++ b/xorg/xserver/Xext/dpms.c
@@ -45,9 +45,9 @@ Equipment Corporation.
 
 CARD16 DPMSPowerLevel = 0;
 Bool DPMSDisabledSwitch = FALSE;
-CARD32 DPMSStandbyTime;
-CARD32 DPMSSuspendTime;
-CARD32 DPMSOffTime;
+CARD32 DPMSStandbyTime = -1;
+CARD32 DPMSSuspendTime = -1;
+CARD32 DPMSOffTime = -1;
 Bool DPMSEnabled;
 
 Bool
@@ -432,7 +432,15 @@ DPMSCloseDownExtension(ExtensionEntry *e)
 void
 DPMSExtensionInit(void)
 {
-DPMSStandbyTime = DPMSSuspendTime = DPMSOffTime = ScreenSaverTime;
+#define CONDITIONALLY_SET_DPMS_TIMEOUT(_timeout_value_) \
+if (_timeout_value_ == -1) { /* not yet set from config */  \
+_timeout_value_ = ScreenSaverTime;  \
+}
+
+CONDITIONALLY_SET_DPMS_TIMEOUT(DPMSStandbyTime)
+CONDITIONALLY_SET_DPMS_TIMEOUT(DPMSSuspendTime)
+CONDITIONALLY_SET_DPMS_TIMEOUT(DPMSOffTime)
+
 DPMSPowerLevel = DPMSModeOn;
 DPMSEnabled = DPMSSupported();
 
___
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] : bug 106963 : change the DPMS initialization to be conditional on not set from config

[Emil Velikov]

Hi John,

On 19 June 2018 at 16:16, John Lumby  wrote:
>
> --- xorg/xserver/Xext/dpms.c.orig   2018-06-16 18:54:24.520660890 -0400
> +++ xorg/xserver/Xext/dpms.c2018-06-18 11:09:19.021529381 -0400
> @@ -45,9 +45,9 @@ Equipment Corporation.
>
>  CARD16 DPMSPowerLevel = 0;
>  Bool DPMSDisabledSwitch = FALSE;
> -CARD32 DPMSStandbyTime;
> -CARD32 DPMSSuspendTime;
> -CARD32 DPMSOffTime;
> +CARD32 DPMSStandbyTime = -1;
> +CARD32 DPMSSuspendTime = -1;
> +CARD32 DPMSOffTime = -1;
>  Bool DPMSEnabled;
>
>  Bool
> @@ -432,7 +432,15 @@ DPMSCloseDownExtension(ExtensionEntry *e
>  void
>  DPMSExtensionInit(void)
>  {
> -DPMSStandbyTime = DPMSSuspendTime = DPMSOffTime = ScreenSaverTime;
> +#define CONDITIONALLY_SET_DPMS_TIMEOUT(_timeout_value_) \
> +if (_timeout_value_ == -1) { /* not yet set from config */  \
> +_timeout_value_ = ScreenSaverTime;  \
> +}
> +
> +CONDITIONALLY_SET_DPMS_TIMEOUT(DPMSStandbyTime)
> +CONDITIONALLY_SET_DPMS_TIMEOUT(DPMSSuspendTime)
> +CONDITIONALLY_SET_DPMS_TIMEOUT(DPMSOffTime)
> +
>  DPMSPowerLevel = DPMSModeOn;
>  DPMSEnabled = DPMSSupported();

Functionality-wise the patch looks spot on. Can you please tweak the
formatting/commit message.
The specifics are listed here [1] although the gist is:
 - in the commit message explain why patch is needed - Otherwise any
user settings in xorg.conf will be discarded
 - use the full URL for bugzilla references - Fixes: https...
 - use git to manage/send patches - git send-email
--subject-prefix="PATCH xserver" --to=xorg-devel@lists.x.org ...

HTH
Emil

[1] https://www.x.org/wiki/Development/Documentation/SubmittingPatches/
___
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 xorgproto 1/2] Remove the use of no-op B16 & B32 bitfield macros in headers

[Emil Velikov]

On 18 June 2018 at 01:30, Keith Packard  wrote:
> Alan Coopersmith  writes:
>
>> These have always done nothing on all platforms except CRAY.
>> As https://bugs.freedesktop.org/show_bug.cgi?id=45202 points out
>> we don't even detect when they've been wrong for decades.
>>
>> Performed via:
>> find include -name '*.h' | grep -v md.h | xargs perl -i -p -e 's{\s+B\d+}{}g'
>> followed by manual whitespace fixups to preserve visual alignment.
>>
>> The #defines for B16 & B32 are left in place to preserve compatibility
>> in any code that used them outside the xorgproto repo.
>>

Good call about keeping those. Quick look shows a handful of users:

app/lbxproxy
app/xfs

driver/xf86-video-sis
driver/xf86-video-sisusb
driver/xf86-video-via
driver/xf86-video-vmware

lib/libICE
lib/libICE
lib/liblbxutil
lib/libSM
lib/libX11
lib/libxkbfile

mesa/drm
mesa/mesa - dri1, appledri, windowsdri copies

xserver - same as mesa

>> Signed-off-by: Alan Coopersmith 
>
> Acked-by: Keith Packard 
>

Reviewed-by: Emil Velikov 

HTH
Emil
___
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] release: fix mesa url detection after migration to gitlab

[Dylan Baker]

Quoting Dylan Baker (2018-06-15 14:12:55)
> Mesa's migration to gitlab has changed the URL and made things not work.
> ---
>  release.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/release.sh b/release.sh
> index b2071b6..6b8e441 100755
> --- a/release.sh
> +++ b/release.sh
> @@ -240,7 +240,7 @@ get_section() {
> module_url=`echo $module_url | cut -d'/' -f3,4`
>  else
> # The look for mesa, xcb, etc...
> -   module_url=`echo "$full_module_url" | $GREP -o -e "/mesa/.*" -e 
> "/xcb/.*" -e "/xkeyboard-config" -e "/nouveau/xf86-video-nouveau" -e 
> "/libevdev" -e "/wayland/.*" -e "/evemu"`
> +   module_url=`echo "$full_module_url" | $GREP -o -e "mesa/.*" -e 
> "/xcb/.*" -e "/xkeyboard-config" -e "/nouveau/xf86-video-nouveau" -e 
> "/libevdev" -e "/wayland/.*" -e "/evemu"`
> if [ $? -eq 0 ]; then
>  module_url=`echo $module_url | cut -d'/' -f2,3`
> else
> -- 
> 2.17.1
> 

I should probably also mention I don't have (or want) Xorg push access :)

Dylan


signature.asc
Description: signature
___
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] release: fix mesa url detection after migration to gitlab

[Emil Velikov]

On 15 June 2018 at 22:12, Dylan Baker  wrote:
> Mesa's migration to gitlab has changed the URL and made things not work.

Thanks for the fixup Dylan.

Reviewed-by: Emil Velikov 

-Emil
___
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] : bug 106963 : change the DPMS initialization to be conditional on not set from config

[John Lumby]

--- xorg/xserver/Xext/dpms.c.orig   2018-06-16 18:54:24.520660890 -0400
+++ xorg/xserver/Xext/dpms.c2018-06-18 11:09:19.021529381 -0400
@@ -45,9 +45,9 @@ Equipment Corporation.
 
 CARD16 DPMSPowerLevel = 0;
 Bool DPMSDisabledSwitch = FALSE;
-CARD32 DPMSStandbyTime;
-CARD32 DPMSSuspendTime;
-CARD32 DPMSOffTime;
+CARD32 DPMSStandbyTime = -1;
+CARD32 DPMSSuspendTime = -1;
+CARD32 DPMSOffTime = -1;
 Bool DPMSEnabled;
 
 Bool
@@ -432,7 +432,15 @@ DPMSCloseDownExtension(ExtensionEntry *e
 void
 DPMSExtensionInit(void)
 {
-DPMSStandbyTime = DPMSSuspendTime = DPMSOffTime = ScreenSaverTime;
+#define CONDITIONALLY_SET_DPMS_TIMEOUT(_timeout_value_) \
+if (_timeout_value_ == -1) { /* not yet set from config */  \
+_timeout_value_ = ScreenSaverTime;  \
+}
+
+CONDITIONALLY_SET_DPMS_TIMEOUT(DPMSStandbyTime)
+CONDITIONALLY_SET_DPMS_TIMEOUT(DPMSSuspendTime)
+CONDITIONALLY_SET_DPMS_TIMEOUT(DPMSOffTime)
+
 DPMSPowerLevel = DPMSModeOn;
 DPMSEnabled = DPMSSupported();
___
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: A question about XCompositeRedirectSubwindows

[Jasper St. Pierre]

Hi,

(Re-adding xorg-devel. Please make sure to keep the list CC'd in the future)

It is possible for a window to set "no background color", in which case the
existing window contents are used for the pixmap. xclock likely sets no
background color. You can check an individual window's properties with
xwininfo.

Redrawing the screen every frame isn't a bad idea for a simple compositor
to get started. For a more fancy, complete redraw loop, you can track when
windows get drawn to with with the Damage extension, and schedule a repaint
when that happens. Bonus points if you use the damage rectangles to be more
accurate with your redraw. Also, helpful hint that windows get their
backing pixmaps thrown away when resized -- you need to pay attention to
ConfigureNotify and regrab the backing pixmap with
XCompositeNameWindowPixmap, and that whole jazz.

I don't recommend synthesizing input events -- a lot of things are likely
to break or just not work well. Set an empty input shape on the COW, and
make sure to draw windows where they want to be. Pay attention to
MotionNotify events from windows that are moving.

I'm unaware of any beginner-level documentation or tutorials. The number of
people that have written a compositing manager from scratch can be counted
on one hand, and a lot of them had a hand in designing the architecture to
begin with. https://magcius.github.io/xplain/article/composite.html has
some ideas of the broader concepts, but none of the details.

Good luck.

On Tue, Jun 19, 2018 at 2:01 AM Egil Möller 
wrote:

> Hi!
>
> Thanks for answering a noob question :) Ha! That's so not documented (in
> an obvious way)! I was assuming that I could get the initial window
> content, as already drawn (obviously clipped to whatever is visible on
> screen) directly... So why does xclock "work" then? I just haven't gotten
> around to event handling yet, wanted to learn the drawing/copying methods
> themselves first...
>
> Two follow up questions:
>
>   * How should I redraw the screen? As often as I can, or waiting for some
> event for all redirected windows (which event)?
>   * Can I capture input events (key, mouse) for the overlay window and
> then somehow synthesize them for whatever window / subwindow my window
> manager thinks it has drawn in that position? Some docs I read sounded like
> this is impossible, and you should turn of input for the overlay, and
> position the real window underneath in a "strategic position"...
>
> Also, is there any good documentation and/or tutorials around this
> anywhere?
>
> /Egil
>
> On 19. juni 2018 08:42, Jasper St. Pierre wrote:
>
> Hi,
>
> What you're seeing here is a fun little side effect of composite. As you
> might be aware, unredirected X windows don't have any backing storage
> beyond the front buffer -- the full window contents are not really there.
> That means that when the X server first goes to redirect these windows, it
> decides that it should let the window paint again, and sends the window an
> Expose event to let it know it should repaint. A side effect of this is
> that the X server redraws the background for the window. This is the
> semantics for what an Expose event means -- an area that is "Exposed" is
> the background color until the client paints over it.
>
> The client will eventually paint its window contents, but since your CM
> does not appear to have a frame loop, and it only paints once, you do not
> see the updated frame contents.
>
> On Sun, Jun 17, 2018 at 1:28 PM Egil Möller 
> wrote:
>
>> Hi!
>>
>> I'm trying to write a new compositing window manager, and finding the
>> documentation for the API:s I need quite spread out.
>>
>> The particular problem I'm having right now is that copying some windows
>> (xclock) using
>> XCompositeRedirectSubwindows and e.g. XRenderComposite works fine, while
>> other windows (xterm, xlock) leaves me we a square with only their
>> background color. This seems to be true for both XRenderComposite and
>> glXBindTexImageEXT. Any ideas what's different between them, and what I
>> need to do differently?
>>
>> My code is here: https://github.com/redhog/InfiniteGlass
>> (main code is in wm.c; running "make" ahould give you an Xephyr nested X
>> session that shows the problem).
>>
>> Thanks in advance,
>>
>> Egil Möller
>>
>>
>>
>> ___
>> 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
>
>
>
> --
>   Jasper
>
>
>

-- 
  Jasper
___
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/xauth 2/2] Sort entries from most specific to most generic.

[Walter Harms]

> Michal Srb  hat am 7. Juni 2018 um 16:01 geschrieben:
> 
> 
> On čtvrtek 7. června 2018 14:59:44 CEST Walter Harms wrote:
> > I was thinking about a more permanent solution and sofar i see the correct
> > way would to add the two functions to libXau since i do not see that other
> > applications would be more clever that xauth.
> 
> That would be nice, sadly libXau does not provide any functions to manipulate 
> the list of xauth records. Just functions for writing and reading of a single 
> record, locking and matching.
> 
> One option would be to change the semantics of XauGetBestAuthByAddr to return 
> the most precise match first, instead of returning the first match of any 
> kind. But I don't think changing that behavior is good idea.
> 
> Alternatively we can just take the patch #1, so that xauth does overwrite 
> records with other random records. I believe that is correct fix. And we can 
> ignore this patch #2 that does the sorting. I could probably workaround my 
> issue by invoking xauth differently. (I could create 1-item list first 
> containing the new record and then merge the original list into it, so the new
> 
> record will end up on top.)
> 
> Michal Srb


I am waiting if someone will complain, if nothing happens until fr. i will see
to add your patch and will mail you for testing.

re,
 wh
___
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: Grabbing modesetting ddx related patches for pull request

[Tony Lindgren]

* Lyude Paul  [180618 20:50]:
> To help ajax out with getting a bug release out for Xorg, we figured it would
> be a good idea for me to go through the stuff I needed to get upstream and
> file pull requests for all of it. This is pretty much the same thing as what
> I'm doing for EGLStreams stuff in Xwayland, except for modesetting.
> 
> For starters, my current WIP branch for this pull lives at:
> 
> https://gitlab.freedesktop.org/lyudess/xserver/tree/wip/modesetting-pull
> 
> This contains all the modesetting patches on patchwork I could find that have
> been reviewed and are ready to go. Additionally, there's a rather important
> fix for the modesetting ddx regarding the new partial atomic support that I
> haven't written up yet that will be included in this too.
> 
> Other then that, there's currently some patches on the ML that I found which
> need reviews:
> 
>  * "modesetting: Update fb_id from shadow allocate and destroy if not set"
>from Tony Lindgren:
>https://patchwork.freedesktop.org/patch/203834/

Thanks for picking this one up. And yes that's the improved
version that I never received any comments for.

>  * "modesetting: Allow a DRM fd to be passed on command line with -masterfd"
>from Keith Packard
>https://patchwork.freedesktop.org/patch/207655/
> 
> I will try to give a review of these, but reviews from others would be
> appreciated as well since there are probably people a lot more experienced
> with this ddx than I on this list :).
> 
> If I've missed anyone's patches, please feel free to respond to this email.
> I'll give an update when I think it's ready for pulling time (which should
> hopefully not be too long from now).

Things have been working just fine for me with the
just patch above thanks :)

Regards,

Tony
___
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: A question about XCompositeRedirectSubwindows

[Jasper St. Pierre]

Hi,

What you're seeing here is a fun little side effect of composite. As you
might be aware, unredirected X windows don't have any backing storage
beyond the front buffer -- the full window contents are not really there.
That means that when the X server first goes to redirect these windows, it
decides that it should let the window paint again, and sends the window an
Expose event to let it know it should repaint. A side effect of this is
that the X server redraws the background for the window. This is the
semantics for what an Expose event means -- an area that is "Exposed" is
the background color until the client paints over it.

The client will eventually paint its window contents, but since your CM
does not appear to have a frame loop, and it only paints once, you do not
see the updated frame contents.

On Sun, Jun 17, 2018 at 1:28 PM Egil Möller 
wrote:

> Hi!
>
> I'm trying to write a new compositing window manager, and finding the
> documentation for the API:s I need quite spread out.
>
> The particular problem I'm having right now is that copying some windows
> (xclock) using
> XCompositeRedirectSubwindows and e.g. XRenderComposite works fine, while
> other windows (xterm, xlock) leaves me we a square with only their
> background color. This seems to be true for both XRenderComposite and
> glXBindTexImageEXT. Any ideas what's different between them, and what I
> need to do differently?
>
> My code is here: https://github.com/redhog/InfiniteGlass
> (main code is in wm.c; running "make" ahould give you an Xephyr nested X
> session that shows the problem).
>
> Thanks in advance,
>
> Egil Möller
>
>
>
> ___
> 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



-- 
  Jasper
___
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