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 xserver] dix: do not send focus event when grab actually does not change
Hello,
Ping?
Samuel
Samuel Thibault, le mar. 30 oct. 2018 18:43:51 +0100, a ecrit:
> c67f2eac5651 ("dix: always send focus event on grab change") made dix
> always sent events when it's a NotifyGrab or NotifyUngrab, even if
> from == to, because 'from' can just come from a previous XSetInputFocus
> call.
>
> However, when an application calls XGrabKeyboard several times on
> the same window, we are now sending spurious FocusOut+FocusIn with
> NotifyGrab, even if the grab does not actually change. This makes screen
> readers for blind people spuriously emit activity events which disturb
> screen reading workflow when e.g. switching between menus.
>
> This commit avoids calling DoFocusEvents in that precise case, i.e. when
> oldWin is a previous grab and the new grab is the same window.
>
> Signed-off-by: Samuel Thibault
>
> Index: xorg-server-1.19.2/dix/events.c
> ===
> --- xorg-server-1.19.2.orig/dix/events.c
> +++ xorg-server-1.19.2/dix/events.c
> @@ -1530,7 +1530,9 @@ ActivatePointerGrab(DeviceIntPtr mouse,
> mouse->spriteInfo->sprite->hotPhys.y = 0;
> ConfineCursorToWindow(mouse, grab->confineTo, FALSE, TRUE);
> }
> -DoEnterLeaveEvents(mouse, mouse->id, oldWin, grab->window, NotifyGrab);
> +if (! (grabinfo->grab && oldWin == grabinfo->grab->window
> + && oldWin == grab->window))
> +DoEnterLeaveEvents(mouse, mouse->id, oldWin, grab->window,
> NotifyGrab);
> mouse->valuator->motionHintWindow = NullWindow;
> if (syncEvents.playingEvents)
> grabinfo->grabTime = syncEvents.time;
> @@ -1640,7 +1642,9 @@ ActivateKeyboardGrab(DeviceIntPtr keybd,
> oldWin = keybd->focus->win;
> if (keybd->valuator)
> keybd->valuator->motionHintWindow = NullWindow;
> -if (oldWin)
> +if (oldWin &&
> + ! (grabinfo->grab && oldWin == grabinfo->grab->window
> + && oldWin == grab->window))
> DoFocusEvents(keybd, oldWin, grab->window, NotifyGrab);
> if (syncEvents.playingEvents)
> grabinfo->grabTime = syncEvents.time;
___
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
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
Repos to archive?
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: https://gitlab.freedesktop.org/xorg/app/compiz - This is a long abandoned repo, not actual upstream, right? https://gitlab.freedesktop.org/xorg/app/intel-gen4asm - Last commit was to declare the repo DEPRECATED as it folded into the gpu-tools repo instead. https://gitlab.freedesktop.org/xorg/app/lbxproxy - This can't be built without liblbxutil which is already archived. https://gitlab.freedesktop.org/xorg/app/makepsres - leftover bit of DPS that never even got a Makefile created https://gitlab.freedesktop.org/xorg/app/mkcfm - MAINTAINERS file says "Obsolete - CID font support has been dropped" https://gitlab.freedesktop.org/xorg/app/proxymngr - This can't be built without lbxproxy (see above) https://gitlab.freedesktop.org/xorg/app/xrx - All major browsers have dropped NSAPI plugin support now https://gitlab.freedesktop.org/xorg/app/xsetmode https://gitlab.freedesktop.org/xorg/app/xsetpointer - The READMEs explain why these are useless now https://gitlab.freedesktop.org/xorg/app/xtrap - See https://lists.freedesktop.org/archives/xorg/2008-June/036131.html https://gitlab.freedesktop.org/xorg/driver/xf86-video-imstt - Last commit is "Fail configure. This driver is unmaintained" 8 years ago https://gitlab.freedesktop.org/xorg/font/bitstream-speedo -Speedo is listed on https://www.x.org/wiki/DeprecatedInX11R7/ as not supported in modular builds. The code was deleted from libXfont in 2009. https://gitlab.freedesktop.org/xorg/lib/libxkbcommon - Last commit is notice of moving to github 5 years ago https://gitlab.freedesktop.org/xorg/lib/libxcwm - Is anyone using this? No commits in 6 years... https://gitlab.freedesktop.org/xorg/util/xmkmf - Last commit was 12 years ago: "xmkmf support was moved to imake package." (To see those already archived, visit https://gitlab.freedesktop.org/groups/xorg/-/archived .) -- -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
