Re: Dead key behavior on Linux / X11
Hello, Tigran S., le jeu. 21 avril 2022 12:33:06 +0400, a ecrit: > in macOS, I can type that word without a space between t and k dead > keys. > Is it possible to have such an implementation of dead keys in Linux? That can be encoded in the XCompose table, yes, see for instance el_GR.UTF-8/Compose.pre that has the various dead_* combinations. Samuel
Re: xf86-video-dummy compared to xf86-video-dummy-with-vt?
John T Davis, le mar. 07 juil. 2020 16:01:12 -0500, a ecrit: > Would you mind if I reposted this explanation on the Manjaro Linux forum? You're welcome! Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xf86-video-dummy compared to xf86-video-dummy-with-vt?
Hello, John T Davis, le lun. 06 juil. 2020 23:12:52 -0500, a ecrit: > How does this version of the driver differ from the xf86-video-dummy (that is, > without the virtual terminal)? What exactly is different for the end user? The difference is that the user can actually type on the PC keyboard and things work as expected. For instance, control-C doesn't kill the X server. Put another way, with this patch the X server behaves very much like a normal X server, except that it doesn't display anything. > Would switching to the with-vt driver give me access to the TTY consoles over > SSH? No. It really is not the purpose. Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xf86-video-dummy license clarification
Lars-Dominik Braun, le dim. 14 juin 2020 09:11:05 +0200, a ecrit: > Xorg’s dummy driver lacks a clear open source license statement[1]. Its > COPYING file simply states “Copyright 2002, SuSE Linux AG”, indicating > it is non-free software. Is that correct? I see Debian is distributing > the driver under the terms of the X11 license[2], so is Gentoo Linux[3]. The driver's origin come from xfree86's X11-licensed server, see http://snapshot.debian.org/archive/debian/20050312T00Z/pool/main/x/xfree86/xfree86_4.3.0.dfsg.1.orig.tar.gz ./programs/Xserver/hw/xfree86/drivers/dummy/dummy_driver.c ./programs/Xserver/hw/xfree86/doc/LICENSE Apparently it was forgotten to copy over the license file. Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: X server does not have an option to specify which address to listen on for TCP connections
ornx, le lun. 11 mai 2020 14:38:48 +, a ecrit: > >X was intended to be used on desktops > is this really true? Xorg, yes. > is the reason why this behavior has not been implemented in Xorg simply > because nobody has thought to add it, Most probably. If you don't find in the list archive anybody proposing such a feature, it means nobody thought to add it :) Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How complex would be to recode Xorg so it allow Me to use Unix sockets instead of TCP/IP sockets
Mgr. Janusz Chmiel, le mer. 29 avril 2020 21:05:02 +0200, a ecrit: > I Am using Dummi video driver because graphical output is useless for Me I > do not see at all. Understood. Again, my question is: why do you need to connect through VNC? Is the keyboard not working otherwise? How would people using a non-dummy video driver get the keyboard working? Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How complex would be to recode Xorg so it allow Me to use Unix sockets instead of TCP/IP sockets
Mgr. Janusz Chmiel, le mer. 29 avril 2020 20:45:52 +0200, a ecrit: > I AM using one Android VNC client app from GOogle Play. You are again only telling us what you are doing, not what you are aiming at. It's the latter we need to know to be able to advise you how to do things differently. Otherwise we can only say "well yes that's how it works, with the issues you are getting, and to get rid of the issues you'll have to do the whole thing differently, so do tell us what your actual goal is". So you are running Xorg with the dummy driver on Android. Does Xorg on android not have some support for keyboard? Are sighted users using Xorg really using VNC to access it? Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How complex would be to recode Xorg so it allow Me to use Unix sockets instead of TCP/IP sockets
Mgr. Janusz Chmiel, le mer. 29 avril 2020 20:30:36 +0200, a ecrit: > I AM using The following command. > > x11vnc -display :0 -bg -nopw -listen localhost -xkb -forever -ncache 10 > -noshm >From reading the rest of your mail I realize you are not wondering about security, but about performance. > Tigervnc do not want to support XKB properly, so Orca do not work. That's a completely different question than unix/localhost sockets. > Somebody has told me, that using Xinit XOrg and X11vnc is not > effective. That's indeed not the cheapest toolchain. But I believe we are in an XY problem here (https://en.wikipedia.org/wiki/XY_problem). What is your *actual* goal? AIUI you want to run a desktop with Orca, i.e. you don't care about the actual screen rendering, but you need to type on the keyboard. How do you run vncviewer to connect to x11vnc actually? Really, the proper and efficient way would be to make the Xorg setup with the dummy driver just properly allocate a VT to get keyboard processing going on normally. That's what you'd want some engineer to spend time on. Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How complex would be to recode Xorg so it allow Me to use Unix sockets instead of TCP/IP sockets
Mgr. Janusz Chmiel, le mer. 29 avril 2020 20:25:10 +0200, a ecrit: > Can I do that by using xorg.conf file? Or is it necessary to modify XOrg > source code? It has nothing to do with Xorg, which already uses unix sockets by default (DISPLAY=:0 means unix socket) Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How complex would be to recode Xorg so it allow Me to use Unix sockets instead of TCP/IP sockets
Mgr. Janusz Chmiel, le mer. 29 avril 2020 20:22:33 +0200, a ecrit: > But how to do that? ? Instead of running x11vnc Run x11vnc -listen localhost And only your local vncviewer will be able to connect, not other devices on the network. Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How complex would be to recode Xorg so it allow Me to use Unix sockets instead of TCP/IP sockets
Mgr. Janusz Chmiel, le mer. 29 avril 2020 19:42:46 +0200, a ecrit: > Since on Android device, when I get out of active WIFI site, You can passe -listen localhost to x11vnc, to expose the VNC port only locally. Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xvfb-run seems to start command too early
Hello, Yannick Schinko, le lun. 04 nov. 2019 14:25:43 +, a ecrit: > When using xvfb-run (1.19.2-1+deb9u5) to run gource headless I run into the > issue that the underlying server does not seem to be ready in time a good > 75+% of cases. Note that the xvfb-run script is a Debian script (thus Cc-ing maintainers there just for information), but possibly the issue is inside the Xserver, see below. > In those cases gource complains: > gource: SDL initialization failed - Couldn't find matching GLX visual > > Now this suspicion is amplified because when I run it as "xvfb-run > bash -c "sleep 1; gource " it works every time. > > Is there some way to work around this issue other than having a sleep before > the gource command (which would make working with some scripts a pain)? It happens that the Debian xvfb-run script takes good care of using SIGUSR1 to synchronize with Xvfb (see SIGUSR1 in man Xserver), so I'm surprised that you're running into issues. Perhaps the X server is sending SIGUSR1 too early? Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: xf86-video-dummy driver
Hello, Storm Dragon, le lun. 09 sept. 2019 19:08:43 -0400, a ecrit: > So, I was wondering, have I done something wrong in the configuration, or is > there some weird bug in the driver? It's a driver behavior, yes. Please follow-up on the existing bug tracker entry https://gitlab.freedesktop.org/xorg/driver/xf86-video-dummy/issues/2 Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
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: libpciaccess on GNU/Hurd
Adam Jackson, le jeu. 08 nov. 2018 15:19:41 -0500, a ecrit: > > > If you try to implement this with a userspace arbiter then > > > all you need to do to break it is run an old version of libpciaccess. > > > > Sure. Except if ioperm is allowed only for the pci arbiter. > > ... but that's all you need. Call ioperm, if it succeeds you must be > the arbiter, so you install the x86 backend. Mmm, we could do that in the kernel, yes: only allow one process to access the PCI config ports. Samuel ___ 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: libpciaccess on GNU/Hurd
Adam Jackson, le mer. 07 nov. 2018 15:09:58 -0500, a ecrit: > Because the kernel is the one thing in a position to enforce access > exclusion. root-owned processes can still use ioperm to get access to io ports and break that. > If you try to implement this with a userspace arbiter then > all you need to do to break it is run an old version of libpciaccess. Sure. Except if ioperm is allowed only for the pci arbiter. > > > The 'x86' backend is fundamentally broken (as you've noticed) > > > > How do you see it broken? (considering that the concurrent access issue > > is solved by moving it to a central place) > > 1) PCI configuration space access isn't atomic. Sure, that's what I was talking about. Having only one pci arbiter solves this. > I'll assume that the design you're contemplating has a pci arbiter > server handling the actual port I/O, and that for normal processes > inl/outl would trap and relay the command to the arbiter. Normal process would use the hurd libpciaccess method, i.e. through the pci arbiter. > 2) No support for multiple PCI domains, because the CF8/CFC access > method doesn't have any way to encode a domain. Sure, we'd need to extend this to get support for that. > 3) No support for things that aren't x86. Not a concern for Hurd, > perhaps, but if that's a thing you ever want maybe solve it portably up > front. Sure, again, that'd be extendable later. Really, think the pci arbiter as the kernel driver you are mentioning, simply running in userland, and for now using the libpciaccess x86 method, which is a way to share the implementation. Remember that I did implement that method actually, precisely to have it usable both by GNU/Hurd, but also other projects which would happen to be happy to have it (cygwin seem to have been happy with it). There are various server-based OSes out there which are happy to be able to re-use it, even if they don't take the time to port the configure bits into upstream libpciaccess. Samuel ___ 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: libpciaccess on GNU/Hurd
Hello, Adam Jackson, le mer. 07 nov. 2018 12:04:52 -0500, a ecrit: > On Mon, 2018-11-05 at 22:56 +1100, Damien Zammit wrote: > > > I wish to propose an additional api call to libpciaccess. > > Before I submit a patch, I wish to get some feedback from the devs. > > > > In GNU/Hurd currently, applications use the x86 backend from > > libpciaccess. This poses concurrency issues when multiple applications > > run at the same time accessing pci. > > Thus we want to make libpciaccess do operations through an arbiter. > > The pci arbiter would use libpciaccess to access the x86 methods, but > > then we wish to make applications use the hurd method on top of that. > > What I'd do instead is make a kernel service for this and have the Hurd > backend call that, Why would it _need_ to be a kernel service? > The 'x86' backend is fundamentally broken (as you've noticed) How do you see it broken? (considering that the concurrent access issue is solved by moving it to a central place) > then wat I'd do instead is create a Hurd backend inside > libpciaccess. Change x86_pci_methods to _pci_hidden instead of static, > create a hurd_pci_methods vtable that takes whatever arbitration lock > you want (some lock file in /tmp or whatever) and then calls through > to the x86_pci_methods vtable. Well, there is more to it than just protecting concurrent use of the x86 access code: what we call pci arbiter would also allow to specify which application/user is allowed to see/access what, forward it in containers, possibly using an iommu to make it secure, etc. Samuel ___ 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] dix: do not send focus event when grab actually does not change
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: xorg-server-1.20 freeze if started with "mouse" driver
Piotr Karbowski, le lun. 18 juin 2018 15:20:34 -0400, a ecrit: > I have reproducible issue after upgrading from 1.19.5 to 1.20 xorg-server. If > used with "mouse" driver (x11-drivers/xf86-input-mouse-1.9.2), the system > will complate freeze. I got confirmation from handful of other people that > they have the same issue. > > Any idea how to address that? I cannot switch to libinput or evdev drivers as > I do not run udev on my systems. You need changeset 3c8f243b750a due to the ABI change on xf86GetOS. Apparently 1.9.2 doesn't have it and we need a release. Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[PATCH xserver] dix: always send focus event on grab change
Focus events are useless when 'from' and 'to' are the same. But when this is the result of a (Un)GrabKeyboard request, we should always send them, including when the window manager had previously used XSetInputFocus to specify the focus on a window which happens to be now taking a grab. This is notably needed for window manager using XI to always get keyboard events even during grabs, so they can determine exactly when grabbing is active. Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> --- dix/enterleave.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dix/enterleave.c b/dix/enterleave.c index 1b341f2de..a2f625bc9 100644 --- a/dix/enterleave.c +++ b/dix/enterleave.c @@ -1562,7 +1562,7 @@ DoFocusEvents(DeviceIntPtr pDev, WindowPtr from, WindowPtr to, int mode) if (!IsKeyboardDevice(pDev)) return; -if (from == to) +if (from == to && mode != NotifyGrab && mode != NotifyUngrab) return; CoreFocusEvents(pDev, from, to, mode); -- 2.16.3 ___ 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: NotifyGrab
Hello,
I have kept the story below for the record and attached the testcase
again in case it could be useful.
So the issue is that DoFocusEvents does not send focus events if
from == to, which happens here because the focus-grab.c is calling
XSetInputFocus to set the input focus (as expected for a window manager)
and it happens that it's that window which is requesting a grab, so from
== to. But since it is a grab, we should really emit the focus event, so
that listeners (notably XI listeners) are aware of the grabbing taking
place. I have posted a patch fixing it titled "dix: always send focus
event on grab change" on xorg-devel@lists.x.org for review.
Cheers,
Samuel
Samuel Thibault, le ven. 22 déc. 2017 01:01:04 +0100, a ecrit:
> Samuel Thibault, on jeu. 21 déc. 2017 18:21:39 +0100, wrote:
> > Samuel Thibault, on jeu. 21 déc. 2017 17:50:54 +0100, wrote:
> > > One additionnal piece of information: it seems that what makes compiz
> > > have the issue (compared to my simple X root event listener) is the call
> > > to
> > >
> > > XSetInputFocus (s->dpy (), priv->id, RevertToPointerRoot, CurrentTime);
> > >
> > > on the window that after that acquires the grab.
> >
> > Here are reproducers.
> >
> > - First run focus-grab on a bare X server
> > - then run grab, which opens a window on the top left corner.
> > - Move the mouse to it.
> > -> in focus-grab the enter notify handler calls XSetInputFocus [*]
> > - press the g key
> >
> > The result is this: On the ./grab side:
> >
> > focus out 4194305 0
> > focus in 4194305 0
> > 0: ||
> > 1: |g|
> > 0:1|g|
> > res 0
> >
> > I.e. it got the 'g' keypress event, and successfully called XGrabKeyboard.
> > And on the ./focus-grab side:
> >
> > started
> > create 4194305
> > enter 4194305 0
> > 1
> > core focus out 4194305 0
> > core focus out 38 0
> > core focus out 38 0
> > core focus in 38 0
> > core focus in 4194305 0
> > focus out 6 0
> > key press 7 7 42 0
> > key release 7 7 42 0
> >
> > I.e. it saw the creation of the window, catched entering the window
> > and set XSetInputFocus, which generate focus events, then saw the 'g'
> > keypress (77 is my numlock) but didn't see any grab-related focus
> > events. That's my concern.
>
> And without the XSetInputFocus call, one gets
>
> 1: |g|
> 0:1|g|
> res 0
> focus out 4194305 1
> focus in 4194305 1
>
> and
>
> started
> create 4194305
> enter 4194305 0
> key press 7 7 42 0
> core focus out 4194305 1
> core focus out 38 1
> core focus out 38 1
> core focus in 38 1
> core focus in 4194305 1
> focus out 6 1
> key release 7 7 42 0
>
> i.e. there really is the grab information.
>
> BTW, this is X server core 1.19.5 (Debian Buster up to date)
>
> Samuel
--
Samuel
> dvips -o $@ $<
Faut faire gffe de pas te couper avec ton truc, t'as mis des ciseaux ($<)
partout :))
-+- Dom in Guide du linuxien pervers - "J'aime pas les Makefile !" -+-
#include
#include
#include
#include
#include
#include
#include
int main (int argc, char **argv) {
Display *mydisplay, *mydisplay2;
Window mywindow;
XEvent myevent;
KeySym mykey;
XSizeHints myhint;
XComposeStatus status;
memset(,0,sizeof(status));
int myscreen;
unsigned long myforeground, mybackground, valuemask;
XSetWindowAttributes xswa;
int i;
char text[10];
int done;
mydisplay=XOpenDisplay("");
myscreen=DefaultScreen(mydisplay);
mybackground=WhitePixel(mydisplay, myscreen);
myforeground=BlackPixel(mydisplay, myscreen);
myhint.x=0; myhint.y=0;
myhint.width=400; myhint.height=400;
myhint.flags=PPosition|PSize;
mywindow=XCreateSimpleWindow(mydisplay, DefaultRootWindow (mydisplay), myhint.x, myhint.y, myhint.width, myhint.height, 5 /*border*/, myforeground, mybackground);
XSetWindowBackgroundPixmap(mydisplay, mywindow, None);
XMapRaised(mydisplay, mywindow);
XSelectInput(mydisplay, mywindow, FocusChangeMask | KeyPressMask);
while(1) {
XNextEvent (mydisplay, );
switch(myevent.type) {
case MappingNotify:
XRefreshKeyboardMapping();
break;
case ButtonPress:
fprintf(stderr,"button press\n");
break;
case KeyPress:
i = XLookupString(, text, 10, , );
fprintf(stderr,"%d: |%s|\n",i,text);
if (i == 1 /*len*/ && text[0] == 'q') done = 1;
char buf[128];
int foo;
if (XkbTranslateKeySym(mydisplay, , 0, buf, sizeof(buf), ))
fprintf(stderr,"%d:%d|%s|\n", foo, strlen(buf), buf);
if (myevent.xkey.keycode == 42)
{
int res;
res = XGrabKeyboard (mydisplay, mywindow, True, GrabModeAsync, GrabModeAsync,
Re: NotifyGrab
Samuel Thibault, on jeu. 21 déc. 2017 18:21:39 +0100, wrote: > Samuel Thibault, on jeu. 21 déc. 2017 17:50:54 +0100, wrote: > > One additionnal piece of information: it seems that what makes compiz > > have the issue (compared to my simple X root event listener) is the call > > to > > > > XSetInputFocus (s->dpy (), priv->id, RevertToPointerRoot, CurrentTime); > > > > on the window that after that acquires the grab. > > Here are reproducers. > > - First run focus-grab on a bare X server > - then run grab, which opens a window on the top left corner. > - Move the mouse to it. > -> in focus-grab the enter notify handler calls XSetInputFocus [*] > - press the g key > > The result is this: On the ./grab side: > > focus out 4194305 0 > focus in 4194305 0 > 0: || > 1: |g| > 0:1|g| > res 0 > > I.e. it got the 'g' keypress event, and successfully called XGrabKeyboard. > And on the ./focus-grab side: > > started > create 4194305 > enter 4194305 0 > 1 > core focus out 4194305 0 > core focus out 38 0 > core focus out 38 0 > core focus in 38 0 > core focus in 4194305 0 > focus out 6 0 > key press 7 7 42 0 > key release 7 7 42 0 > > I.e. it saw the creation of the window, catched entering the window > and set XSetInputFocus, which generate focus events, then saw the 'g' > keypress (77 is my numlock) but didn't see any grab-related focus > events. That's my concern. And without the XSetInputFocus call, one gets 1: |g| 0:1|g| res 0 focus out 4194305 1 focus in 4194305 1 and started create 4194305 enter 4194305 0 key press 7 7 42 0 core focus out 4194305 1 core focus out 38 1 core focus out 38 1 core focus in 38 1 core focus in 4194305 1 focus out 6 1 key release 7 7 42 0 i.e. there really is the grab information. BTW, this is X server core 1.19.5 (Debian Buster up to date) Samuel ___ 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: NotifyGrab
Samuel Thibault, on jeu. 21 déc. 2017 17:50:54 +0100, wrote:
> One additionnal piece of information: it seems that what makes compiz
> have the issue (compared to my simple X root event listener) is the call
> to
>
> XSetInputFocus (s->dpy (), priv->id, RevertToPointerRoot, CurrentTime);
>
> on the window that after that acquires the grab.
Here are reproducers.
- First run focus-grab on a bare X server
- then run grab, which opens a window on the top left corner.
- Move the mouse to it.
-> in focus-grab the enter notify handler calls XSetInputFocus [*]
- press the g key
The result is this: On the ./grab side:
focus out 4194305 0
focus in 4194305 0
0: ||
1: |g|
0:1|g|
res 0
I.e. it got the 'g' keypress event, and successfully called XGrabKeyboard.
And on the ./focus-grab side:
started
create 4194305
enter 4194305 0
1
core focus out 4194305 0
core focus out 38 0
core focus out 38 0
core focus in 38 0
core focus in 4194305 0
focus out 6 0
key press 7 7 77 0
key press 7 7 42 0
key release 7 7 42 0
I.e. it saw the creation of the window, catched entering the window
and set XSetInputFocus, which generate focus events, then saw the 'g'
keypress (77 is my numlock) but didn't see any grab-related focus
events. That's my concern.
Samuel
[*] I know it's useless since that's the X server default, but calling
it that way avoids to put into the reproducer the machinery of catching
clicks etc. to call XSetInputFocus at the right point.
#include
#include
#include
#include
#include
#include
#include
char hello[]="hello, World.";
char hi[]="Hi!";
int main (int argc, char **argv) {
Display *mydisplay;
Window mywindow;
XEvent myevent;
KeySym mykey;
XComposeStatus status;
memset(,0,sizeof(status));
int i;
char text[10];
int done;
mydisplay=XOpenDisplay("");
mywindow = DefaultRootWindow(mydisplay);
XSelectInput(mydisplay, DefaultRootWindow(mydisplay),
SubstructureNotifyMask |
StructureNotifyMask |
EnterWindowMask |
FocusChangeMask );
int xi_opcode = -1;
int first_event, first_error;
if (XQueryExtension(mydisplay, "XInputExtension", _opcode, _event, _error))
{
int major = 2;
int minor = 1;
if (XIQueryVersion(mydisplay, , ) != BadRequest) {
XIEventMask eventmask;
unsigned char mask[XIMaskLen (XI_LASTEVENT)] = { 0 };
eventmask.deviceid = XIAllDevices;
eventmask.mask_len = sizeof(mask);
eventmask.mask = mask;
XISetMask (mask, XI_KeyPress);
XISetMask (mask, XI_KeyRelease);
XISetMask (mask, XI_ButtonPress);
XISetMask (mask, XI_ButtonRelease);
XISetMask (mask, XI_Motion);
XISetMask (mask, XI_FocusIn);
XISetMask (mask, XI_FocusOut);
XISelectEvents (mydisplay, mywindow, , 1);
}
}
done=0;
fprintf(stderr,"started\n");
while(done==0) {
XNextEvent (mydisplay, );
switch(myevent.type) {
case KeyPress:
i = XLookupString(, text, 10, , );
fprintf(stderr,"%d: |%s|\n",i,text);
if (i == 1 /*len*/ && text[0] == 'q') done = 1;
char buf[128];
int foo;
if (XkbTranslateKeySym(mydisplay, , 0, buf, sizeof(buf), ))
fprintf(stderr,"%d:%ld|%s|\n", foo, strlen(buf), buf);
break;
case KeyRelease:
break;
case FocusIn:
fprintf(stderr, "core focus in %ld %d\n", myevent.xfocus.window, myevent.xfocus.mode);
break;
case FocusOut:
fprintf(stderr, "core focus out %ld %d\n", myevent.xfocus.window, myevent.xfocus.mode);
break;
case EnterNotify:
fprintf(stderr, "enter %ld %d\n", myevent.xcrossing.window, myevent.xcrossing.mode);
printf("%d\n", XSetInputFocus (mydisplay, myevent.xcrossing.window, RevertToPointerRoot, CurrentTime));
break;
case LeaveNotify:
fprintf(stderr, "leave %ld %d\n", myevent.xcrossing.window, myevent.xcrossing.mode);
break;
case GenericEvent:
if (myevent.xcookie.extension == xi_opcode) {
XGetEventData(mydisplay, );
XIRawEvent *xiRawEv = (XIRawEvent *) myevent.xcookie.data;
XIDeviceEvent *xiDevEv = (XIDeviceEvent *) myevent.xcookie.data;
XIEnterEvent *xiEntEv = (XIEnterEvent *) myevent.xcookie.data;
switch (myevent.xcookie.evtype) {
case XI_KeyPress:
fprintf(stderr,"key press %d %d %d %x\n", xiRawEv->deviceid, xiRawEv->sourceid, xiRawEv->detail, xiDevEv->flags);
break;
case XI_KeyRelease:
fprintf(stderr,"key release %d %d %d %x\n", xiRawEv->deviceid, xiRawEv->sourceid, xiRawEv->detail, xiDevEv->flags);
break;
case XI_FocusIn:
fprintf(stderr, "focus in %d %d\n", xiEntEv->detail, xiEntEv->mode);
break;
case XI_FocusOut:
fprintf(stderr, "focus out %d %d\n", xiEntEv->detail, xiEntEv->mode);
break;
}
XFreeEventData(mydisplay, );
} else {
fprintf(s
Re: NotifyGrab
Hello, One additionnal piece of information: it seems that what makes compiz have the issue (compared to my simple X root event listener) is the call to XSetInputFocus (s->dpy (), priv->id, RevertToPointerRoot, CurrentTime); on the window that after that acquires the grab. Samuel Samuel Thibault, on ven. 24 nov. 2017 12:04:27 +0100, wrote: > Samuel Thibault, on ven. 24 nov. 2017 11:55:49 +0100, wrote: > > Jasper St. Pierre, on jeu. 23 nov. 2017 14:31:32 -0800, wrote: > > > Selecting for XI2 events will disable core input events from being sent > > > to your > > > client. > > > > I forgot to mention: I'm not getting these focus events in Compiz even > > without selecting for XI2, and selecting for XI2 focus events does not > > bring XI_FocusIn/Out events either. > > I mean, I do get XI_FocusIn/Out events, but not at the moment when the > application calls XGrabKeyboard(), and not even when the application > receives a KeyPress event (and Compiz too since it receives it via XI2, > that's precisely the problem: it needs to know that this KeyPress > happened while grabbing was in effect). > > > > On Thu, Nov 23, 2017 at 8:37 AM, Samuel Thibault <[1] > > > samuel.thiba...@ens-lyon.org> wrote: > > > > > > Hello, > > > > > > I'm working on making compiz use XI2 to get more fine-grain hold > > > on keypresses. I'm however getting an issue: I do not always get > > > NotifyGrab FocusIn events from the root window when a client calls > > > > > > XGrabKeyboard (mydisplay, mywindow, True, GrabModeAsync, > > > GrabModeAsync, > > > CurrentTime); > > > > > > , which prevents from properly respecting grabbing. > > > > > > > > > Unfortunately, I didn't manage to reproduce the issue with a simpler X > > > root event listener: runnning > > > > > > XSelectInput(mydisplay, DefaultRootWindow(mydisplay), > > > FocusChangeMask); > > > > > > does properly bring focus out/in NotifyGrab events, but these events > > > don't get to Compiz. I also tried to listen on the window itself with > > > the same result: my simple event listener gets the event, but Compiz > > > does not. > > > > > > Oddly enough, this seems to depend on the application: kvm / > > > virtualbox > > > grabbing have the issue, but vncviewer grabbing doesn't have the > > > issue. > > > > > > Reading [2]https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html > > > tells me > > > that there should always be FocusIn / FocusOut events being generated, > > > so I don't immediately see where to look for in the differences > > > between > > > by simple listener and Compiz. > > > > > > Could there be some undocumented cases where such events are not > > > generated? Any idea where I could look in the X server to check what > > > is > > > happening? > > > > > > Samuel > > > ___ > > > [3]xorg-devel@lists.x.org: X.Org development > > > Archives: [4]http://lists.x.org/archives/xorg-devel > > > Info: [5]https://lists.x.org/mailman/listinfo/xorg-devel > > > > > > > > > > > > > > > -- > > > Jasper > > > > > > References: > > > > > > [1] mailto:samuel.thiba...@ens-lyon.org > > > [2] https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html > > > [3] mailto:xorg-devel@lists.x.org > > > [4] http://lists.x.org/archives/xorg-devel > > > [5] https://lists.x.org/mailman/listinfo/xorg-devel > > > > > ___ > > > 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 > > > > > > -- > > Samuel > > J'ai un gros problème: j'ai cet exercice à rendre demain lundi, mais ma > > TI 89 ne sait pas le faire... > > Est-ce que quelqu'un pourrait m'aider?? > > -+- OD In Guide du Neuneu Usenet : Comment ça ! Il faut réfléchir ?-+- > > -- > Samuel > l'alim je sais où elle est, elle est juste à côté de la dame qui dort > B: clairement faut revoir les priorités dans la vie > B: une dame ça se retrouve, un uptime... -- Samuel update-menus: relocation error: update-menus: symbol _ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E, version GLIBCPP_3.2 not defined in file libstdc++.so.5 with link time reference quoi que ça peut bien vouloir dire ? N a eu la meme merde c ça que ça veut dire ? wow, c'est bien crypté :) -+- #ens-mim s'entraide -+- ___ 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: NotifyGrab
Samuel Thibault, on ven. 24 nov. 2017 11:55:49 +0100, wrote: > Jasper St. Pierre, on jeu. 23 nov. 2017 14:31:32 -0800, wrote: > > Selecting for XI2 events will disable core input events from being sent to > > your > > client. > > I forgot to mention: I'm not getting these focus events in Compiz even > without selecting for XI2, and selecting for XI2 focus events does not > bring XI_FocusIn/Out events either. I mean, I do get XI_FocusIn/Out events, but not at the moment when the application calls XGrabKeyboard(), and not even when the application receives a KeyPress event (and Compiz too since it receives it via XI2, that's precisely the problem: it needs to know that this KeyPress happened while grabbing was in effect). Samuel > Samuel > > > On Thu, Nov 23, 2017 at 8:37 AM, Samuel Thibault <[1] > > samuel.thiba...@ens-lyon.org> wrote: > > > > Hello, > > > > I'm working on making compiz use XI2 to get more fine-grain hold > > on keypresses. I'm however getting an issue: I do not always get > > NotifyGrab FocusIn events from the root window when a client calls > > > > XGrabKeyboard (mydisplay, mywindow, True, GrabModeAsync, GrabModeAsync, > > CurrentTime); > > > > , which prevents from properly respecting grabbing. > > > > > > Unfortunately, I didn't manage to reproduce the issue with a simpler X > > root event listener: runnning > > > > XSelectInput(mydisplay, DefaultRootWindow(mydisplay), FocusChangeMask); > > > > does properly bring focus out/in NotifyGrab events, but these events > > don't get to Compiz. I also tried to listen on the window itself with > > the same result: my simple event listener gets the event, but Compiz > > does not. > > > > Oddly enough, this seems to depend on the application: kvm / virtualbox > > grabbing have the issue, but vncviewer grabbing doesn't have the issue. > > > > Reading [2]https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html > > tells me > > that there should always be FocusIn / FocusOut events being generated, > > so I don't immediately see where to look for in the differences between > > by simple listener and Compiz. > > > > Could there be some undocumented cases where such events are not > > generated? Any idea where I could look in the X server to check what is > > happening? > > > > Samuel > > ___ > > [3]xorg-devel@lists.x.org: X.Org development > > Archives: [4]http://lists.x.org/archives/xorg-devel > > Info: [5]https://lists.x.org/mailman/listinfo/xorg-devel > > > > > > > > > > -- > > Jasper > > > > References: > > > > [1] mailto:samuel.thiba...@ens-lyon.org > > [2] https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html > > [3] mailto:xorg-devel@lists.x.org > > [4] http://lists.x.org/archives/xorg-devel > > [5] https://lists.x.org/mailman/listinfo/xorg-devel > > > ___ > > 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 > > > -- > Samuel > J'ai un gros problème: j'ai cet exercice à rendre demain lundi, mais ma > TI 89 ne sait pas le faire... > Est-ce que quelqu'un pourrait m'aider?? > -+- OD In Guide du Neuneu Usenet : Comment ça ! Il faut réfléchir ?-+- -- Samuel l'alim je sais où elle est, elle est juste à côté de la dame qui dort B: clairement faut revoir les priorités dans la vie B: une dame ça se retrouve, un uptime... ___ 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: NotifyGrab
Hello, Jasper St. Pierre, on jeu. 23 nov. 2017 14:31:32 -0800, wrote: > Selecting for XI2 events will disable core input events from being sent to > your > client. I forgot to mention: I'm not getting these focus events in Compiz even without selecting for XI2, and selecting for XI2 focus events does not bring XI_FocusIn/Out events either. Samuel > On Thu, Nov 23, 2017 at 8:37 AM, Samuel Thibault <[1] > samuel.thiba...@ens-lyon.org> wrote: > > Hello, > > I'm working on making compiz use XI2 to get more fine-grain hold > on keypresses. I'm however getting an issue: I do not always get > NotifyGrab FocusIn events from the root window when a client calls > > XGrabKeyboard (mydisplay, mywindow, True, GrabModeAsync, GrabModeAsync, > CurrentTime); > > , which prevents from properly respecting grabbing. > > > Unfortunately, I didn't manage to reproduce the issue with a simpler X > root event listener: runnning > > XSelectInput(mydisplay, DefaultRootWindow(mydisplay), FocusChangeMask); > > does properly bring focus out/in NotifyGrab events, but these events > don't get to Compiz. I also tried to listen on the window itself with > the same result: my simple event listener gets the event, but Compiz > does not. > > Oddly enough, this seems to depend on the application: kvm / virtualbox > grabbing have the issue, but vncviewer grabbing doesn't have the issue. > > Reading [2]https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html tells > me > that there should always be FocusIn / FocusOut events being generated, > so I don't immediately see where to look for in the differences between > by simple listener and Compiz. > > Could there be some undocumented cases where such events are not > generated? Any idea where I could look in the X server to check what is > happening? > > Samuel > ___ > [3]xorg-devel@lists.x.org: X.Org development > Archives: [4]http://lists.x.org/archives/xorg-devel > Info: [5]https://lists.x.org/mailman/listinfo/xorg-devel > > > > > -- > Jasper > > References: > > [1] mailto:samuel.thiba...@ens-lyon.org > [2] https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html > [3] mailto:xorg-devel@lists.x.org > [4] http://lists.x.org/archives/xorg-devel > [5] https://lists.x.org/mailman/listinfo/xorg-devel > ___ > 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 -- Samuel J'ai un gros problème: j'ai cet exercice à rendre demain lundi, mais ma TI 89 ne sait pas le faire... Est-ce que quelqu'un pourrait m'aider?? -+- OD In Guide du Neuneu Usenet : Comment ça ! Il faut réfléchir ?-+- ___ 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
NotifyGrab
Hello, I'm working on making compiz use XI2 to get more fine-grain hold on keypresses. I'm however getting an issue: I do not always get NotifyGrab FocusIn events from the root window when a client calls XGrabKeyboard (mydisplay, mywindow, True, GrabModeAsync, GrabModeAsync, CurrentTime); , which prevents from properly respecting grabbing. Unfortunately, I didn't manage to reproduce the issue with a simpler X root event listener: runnning XSelectInput(mydisplay, DefaultRootWindow(mydisplay), FocusChangeMask); does properly bring focus out/in NotifyGrab events, but these events don't get to Compiz. I also tried to listen on the window itself with the same result: my simple event listener gets the event, but Compiz does not. Oddly enough, this seems to depend on the application: kvm / virtualbox grabbing have the issue, but vncviewer grabbing doesn't have the issue. Reading https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html tells me that there should always be FocusIn / FocusOut events being generated, so I don't immediately see where to look for in the differences between by simple listener and Compiz. Could there be some undocumented cases where such events are not generated? Any idea where I could look in the X server to check what is happening? Samuel ___ 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 2/2] xorg-wrapper: fix build without libdrm
Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org>
---
configure.ac | 2 --
hw/xfree86/xorg-wrapper.c | 6 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 7db7187..220478a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -926,8 +926,6 @@ fi
AM_CONDITIONAL(SYSTEMD_LOGIND, [test "x$SYSTEMD_LOGIND" = xyes])
if test "x$SUID_WRAPPER" = xyes; then
-dnl The wrapper uses libdrm headers, so ensure they are available
-PKG_CHECK_MODULES([LIBDRM], $LIBDRM)
dnl This is a define so that if some platforms want to put the wrapper
dnl somewhere else this can be easily changed
AC_DEFINE_DIR(SUID_WRAPPER_DIR, libexecdir, [Where to install the Xorg
binary and Xorg.wrap])
diff --git a/hw/xfree86/xorg-wrapper.c b/hw/xfree86/xorg-wrapper.c
index 22e97ad..75d120a 100644
--- a/hw/xfree86/xorg-wrapper.c
+++ b/hw/xfree86/xorg-wrapper.c
@@ -39,8 +39,10 @@
#include
#endif
#include
+#ifdef WITH_LIBDRM
#include
#include /* For DRM_DEV_NAME */
+#endif
#define CONFIG_FILE SYSCONFDIR "/X11/Xwrapper.config"
@@ -183,7 +185,9 @@ static int on_console(int fd)
int main(int argc, char *argv[])
{
+#ifdef WITH_LIBDRM
struct drm_mode_card_res res;
+#endif
char buf[PATH_MAX];
int i, r, fd;
int kms_cards = 0;
@@ -219,6 +223,7 @@ int main(int argc, char *argv[])
}
}
+#ifdef WITH_LIBDRM
/* Detect if we need root rights, except when overriden by the config */
if (needs_root_rights == -1) {
for (i = 0; i < 16; i++) {
@@ -237,6 +242,7 @@ int main(int argc, char *argv[])
close(fd);
}
}
+#endif
/* If we've found cards, and all cards support kms, drop root rights */
if (needs_root_rights == 0 || (total_cards && kms_cards == total_cards)) {
--
2.6.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xorg-wrapper: fix build without libdrm
Mark Kettenis, le Mon 19 Oct 2015 12:26:27 +0200, a écrit : > > If you're doing this with certain platforms in mind, maybe > > we need to only not check for libdrm on those platforms ? > > Does it make sense at all to use the wrapper on platforms without drm? We need some setuid wrapper, yes, and we'd like to be able to configure whether all users can run it, or only users which are loggued on the console. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xorg-wrapper: fix build without libdrm
Hans de Goede, le Mon 19 Oct 2015 14:40:46 +0200, a écrit : > To me hurd is the exception here. So maybe change the patch to drop > the configure libdrm check for hurd ? Like is done for cygwin and darwin? Sure. > If that is done I'm fine with the #ifdef LIBDRM in the wrapper itself. I have pushed that to my tree on git+ssh://people.freedesktop.org/~sthibaul/xserver-hurd.git branch master-wrapper-nodrm and will resubmit here. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/2] hurd: disable detecting drm
Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> --- configure.ac | 5 + 1 file changed, 5 insertions(+) diff --git a/configure.ac b/configure.ac index e434720..7db7187 100644 --- a/configure.ac +++ b/configure.ac @@ -752,6 +752,11 @@ case $host_os in XF86VIDMODE=no fi ;; + gnu*) + DRM=no + DRI2=no + DRI3=no + ;; *) XQUARTZ=no ;; esac -- 2.6.1 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xorg-wrapper: fix build without libdrm
Hans de Goede, le Mon 19 Oct 2015 10:56:26 +0200, a écrit : > In which case would you want to build without libdrm anyways ? Can you > explain the use-case for this patch ? Systems with no drm support, simply :) Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xorg-wrapper: fix build without libdrm
Hans de Goede, le Mon 19 Oct 2015 10:56:26 +0200, a écrit : > On 19-10-15 10:53, Samuel Thibault wrote: > >Hans de Goede, le Mon 19 Oct 2015 10:44:30 +0200, a écrit : > >>>@@ -237,6 +242,7 @@ int main(int argc, char *argv[]) > >>> close(fd); > >>> } > >>> } > >>>+#endif > >>> > >> > >>This turns needs_root_rights=auto into needs_root_rights=yes do we really > >>want that > >>when not building with libdrm ? > > > >When not building with libdrm we can't detect if it needs root rights. > > Right, but I'm not sure that means that just running as root then is the right > thing. I agree it will ensure that everything just works, but from a security > pov it just feels wrong. Well, when building without libdrm (and thus without kms), execution without root will just not work at all. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xorg-wrapper: fix build without libdrm
Samuel Thibault, le Mon 19 Oct 2015 11:25:08 +0200, a écrit : > Hans de Goede, le Mon 19 Oct 2015 11:14:21 +0200, a écrit : > > On 19-10-15 11:03, Samuel Thibault wrote: > > >Hans de Goede, le Mon 19 Oct 2015 10:56:26 +0200, a écrit : > > >>In which case would you want to build without libdrm anyways ? Can you > > >>explain the use-case for this patch ? > > > > > >Systems with no drm support, simply :) > > > > Actually I do not think it is that simple, e.g. IIRC the openbsd > > people have their own solution for non requiring root rights. > > I don't see where this happens on the xorg wrapper. Ah, but I guess they just don't use the xorg wrapper then. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xorg-wrapper: fix build without libdrm
Hans de Goede, le Mon 19 Oct 2015 10:44:30 +0200, a écrit : > >@@ -237,6 +242,7 @@ int main(int argc, char *argv[]) > > close(fd); > > } > > } > >+#endif > > > > This turns needs_root_rights=auto into needs_root_rights=yes do we really > want that > when not building with libdrm ? When not building with libdrm we can't detect if it needs root rights. AIUI XORG_DRIVER_MODESETTING is only enabled when building with drm, which needs libdrm. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xorg-wrapper: fix build without libdrm
Hans de Goede, le Mon 19 Oct 2015 11:14:21 +0200, a écrit : > On 19-10-15 11:03, Samuel Thibault wrote: > >Hans de Goede, le Mon 19 Oct 2015 10:56:26 +0200, a écrit : > >>In which case would you want to build without libdrm anyways ? Can you > >>explain the use-case for this patch ? > > > >Systems with no drm support, simply :) > > Actually I do not think it is that simple, e.g. IIRC the openbsd > people have their own solution for non requiring root rights. I don't see where this happens on the xorg wrapper. > Also with your patch people may accidentally end up build the > root-wrapper on Linux without libdrm resulting in a root-wrapper > which will just always launch the xserver as root. Which will be needed anyway if they want to see the X server working at all on Linux. > If you're doing this with certain platforms in mind, maybe > we need to only not check for libdrm on those platforms ? You mean hardcoding the set of such platforms inside xorg-wrapper.c? Well, that'd be at least cygwin (though the wrapper is probably useless there), darwin, hurd. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xorg-wrapper: fix build without libdrm
Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org>
---
configure.ac | 2 --
hw/xfree86/xorg-wrapper.c | 6 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e434720..818026f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -921,8 +921,6 @@ fi
AM_CONDITIONAL(SYSTEMD_LOGIND, [test "x$SYSTEMD_LOGIND" = xyes])
if test "x$SUID_WRAPPER" = xyes; then
-dnl The wrapper uses libdrm headers, so ensure they are available
-PKG_CHECK_MODULES([LIBDRM], $LIBDRM)
dnl This is a define so that if some platforms want to put the wrapper
dnl somewhere else this can be easily changed
AC_DEFINE_DIR(SUID_WRAPPER_DIR, libexecdir, [Where to install the Xorg
binary and Xorg.wrap])
diff --git a/hw/xfree86/xorg-wrapper.c b/hw/xfree86/xorg-wrapper.c
index 22e97ad..75d120a 100644
--- a/hw/xfree86/xorg-wrapper.c
+++ b/hw/xfree86/xorg-wrapper.c
@@ -39,8 +39,10 @@
#include
#endif
#include
+#ifdef WITH_LIBDRM
#include
#include /* For DRM_DEV_NAME */
+#endif
#define CONFIG_FILE SYSCONFDIR "/X11/Xwrapper.config"
@@ -183,7 +185,9 @@ static int on_console(int fd)
int main(int argc, char *argv[])
{
+#ifdef WITH_LIBDRM
struct drm_mode_card_res res;
+#endif
char buf[PATH_MAX];
int i, r, fd;
int kms_cards = 0;
@@ -219,6 +223,7 @@ int main(int argc, char *argv[])
}
}
+#ifdef WITH_LIBDRM
/* Detect if we need root rights, except when overriden by the config */
if (needs_root_rights == -1) {
for (i = 0; i < 16; i++) {
@@ -237,6 +242,7 @@ int main(int argc, char *argv[])
close(fd);
}
}
+#endif
/* If we've found cards, and all cards support kms, drop root rights */
if (needs_root_rights == 0 || (total_cards && kms_cards == total_cards)) {
--
2.6.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Is Xorg aware of text areas?
Alan Coopersmith, le Mon 13 Jul 2015 17:57:11 -0700, a écrit : On 07/13/15 03:27 PM, James Heald wrote: I'm trying to figure out how I can create some program/script that automatically brings up a keyboard when a text field is active. Therefore I need something to tell me whether or not a text area is active, and I was curious if that's something Xorg would be able to tell me or if it would be the window manager that would get that kind of information. Nope - that's all handled at the toolkit level, well above the X protocol, neither Xorg nor the window manager would know that. Your best bet is to hook into the accessibility frameworks, such as atk there. Or perhaps plug into ibus such. Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[PATCH] openchrome: Do not require libdrm
We can build without it. Proper non-fatal finer libdrm detection is already done below this. Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org diff --git a/configure.ac b/configure.ac index b13cb2c..9e77dc8 100644 --- a/configure.ac +++ b/configure.ac @@ -80,7 +80,7 @@ XORG_DRIVER_CHECK_EXT(XF86DRI, xextproto x11) XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto) # Checks for pkg-config packages -PKG_CHECK_MODULES(XORG, [xorg-server xproto fontsproto libdrm glproto $REQUIRED_MODULES]) +PKG_CHECK_MODULES(XORG, [xorg-server xproto fontsproto glproto $REQUIRED_MODULES]) PKG_CHECK_MODULES(XEXT, [xextproto = 7.0.99.1], HAVE_XEXTPROTO_71=yes; AC_DEFINE(HAVE_XEXTPROTO_71, 1, [xextproto 7.1 available]), HAVE_XEXTPROTO_71=no) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: GSOC New idea - Braille extension for XKB
Hello, Nalin, do you have any news about this GSOC idea? The student proposal deadline is today... Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: GSOC New idea - Braille extension for XKB
Hello, Nalin.x.Linux, le Sun 02 Mar 2014 23:01:27 +0530, a écrit : I would like to make braille extension for XKB(X keyboard extension). Interesting! Let me know if any work in this regard has been undertaken by xorg and if so let me know the existing position thanking you. There is already some basic implementation available, see the brai keyboard layout and its variants. What it does is the PC keyboard driver part. For instance, I use xkb layout fr,brai, and variant oss,, and the grp:shift_caps_toggle xkb option. By pressing shift+capslock, I can switch between my usual french layout and the braille layout. When in braille layout, the sdfjkl keys act as a braille keyboard, and produce Unicode braille patterns (U+28XY). Some variants are provided for left-handed/right-handed, keypad, etc. but the base variant should be already fine for most users. After that, not much is implemented, and a GSOC project would be welcome indeed. For the moment, all I did was to add to brltty-ttb the ability to create a .XCompose file, which typically contains braille_dots_1 : a braille_dots_12 : b braille_dots_14 : c etc., thus automatically turning the Unicode braille patterns to text according to brltty TTB table used to create the .XCompose file. This just works as expected for grade-1. For grade-2, one could use the same principle, but I don't think the trickyness of braille contraction can be expressed with compose. As a consequence, what I believe would be useful to implement in your project would be an input method module, which would take the unicode braille patterns as input, and use liblouis to turn that into text. I don't know which kind of module is most preferred nowadays (SCIM? UIM?) but I guess Xorg people can answer that :) You'll probably want to look for documentation for what an input module is, but basically it is a piece of code which gets in the way of typing text in Xorg, e.g. to type kanjis and things like that which are not mere XKB 1-to-1 translations. At any rate, I'd happily mentor such a project! Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: GSOC New idea - Braille extension for XKB
wettstein...@solnet.ch, le Sun 02 Mar 2014 19:59:22 +0100, a écrit : There is some braille support in the compose mechanism in libX11, see directory modules/im/ximcp. I do not know whether and how it works, though. That is what I described, yues. 1. it is very simple, uses only six keys of the keyboard. It appears the implementation in libX11 uses eight keys, each one corresponds to one bit. The input character is obtained by ORing the bits of the pressed keys. Maybe despite the name, it is something different? No, it is really the same (and actually I made 10 dots being defined, as some braille keyboards have 10 of them!) Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: [PATCHES] fix build on GNU/Hurd with GCC 4.8
Hello,
Pino Toscano, le Wed 28 Aug 2013 17:36:26 +0200, a écrit :
with GCC 4.8, few implicit declaration of function warnings become
errors, breaking the build of xserver on the Hurd.
Attached there are two patches, which apply fine in both master and
server-1.14-branch branches, which fix the errors providing the right
includes:
* the inclusion of hurd.h in Hurd parts should be straightforward
* the move of the arpa/inet.h (which is POSIX) to a move general
location affects any other Unix system with IPv6 support, I hope it is
not a problem for all the supported platforms
Acked-by: Samuel Thibault samuel.thiba...@ens-lyon.org
Could somebody push that to the server? We really need it.
Thanks,
Samuel
From ef6a236cf9b795017c9c8c4447a6735fa04bb061 Mon Sep 17 00:00:00 2001
From: Pino Toscano toscano.p...@tiscali.it
Date: Wed, 28 Aug 2013 17:04:48 +0200
Subject: [PATCH] xfree86/hurd: include hurd.h
Needed for using get_privileged_port.
Signed-off-by: Pino Toscano toscano.p...@tiscali.it
---
hw/xfree86/os-support/hurd/hurd_init.c |1 +
hw/xfree86/os-support/hurd/hurd_mmap.c |1 +
hw/xfree86/os-support/hurd/hurd_video.c |1 +
3 files changed, 3 insertions(+)
diff --git a/hw/xfree86/os-support/hurd/hurd_init.c
b/hw/xfree86/os-support/hurd/hurd_init.c
index 185b2b9..fe1a764 100644
--- a/hw/xfree86/os-support/hurd/hurd_init.c
+++ b/hw/xfree86/os-support/hurd/hurd_init.c
@@ -42,6 +42,7 @@
#include sys/file.h
#include assert.h
#include mach.h
+#include hurd.h
int
xf86ProcessArgument(int argc, char **argv, int i)
diff --git a/hw/xfree86/os-support/hurd/hurd_mmap.c
b/hw/xfree86/os-support/hurd/hurd_mmap.c
index 6ac9efd..8e089ca 100644
--- a/hw/xfree86/os-support/hurd/hurd_mmap.c
+++ b/hw/xfree86/os-support/hurd/hurd_mmap.c
@@ -27,6 +27,7 @@
#includemach.h
#includedevice/device.h
#includemach/machine/mach_i386.h
+#include hurd.h
#include X11/X.h
diff --git a/hw/xfree86/os-support/hurd/hurd_video.c
b/hw/xfree86/os-support/hurd/hurd_video.c
index 72474ba..b3b94c9 100644
--- a/hw/xfree86/os-support/hurd/hurd_video.c
+++ b/hw/xfree86/os-support/hurd/hurd_video.c
@@ -28,6 +28,7 @@
#include mach.h
#include device/device.h
#include mach/machine/mach_i386.h
+#include hurd.h
#include X11/X.h
#include input.h
--
1.7.10.4
From 006b123a801afab44a9e1a3d6e2ff5e1c6415362 Mon Sep 17 00:00:00 2001
From: Pino Toscano toscano.p...@tiscali.it
Date: Wed, 28 Aug 2013 17:15:03 +0200
Subject: [PATCH] os: move arpa/inet.h for any !win32 system
It is needed in IPv6 configurations (for inet_pton) also when
SIOCGIFCONF is not defined.
Signed-off-by: Pino Toscano toscano.p...@tiscali.it
---
os/access.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/os/access.c b/os/access.c
index 88a44d9..6d991b3 100644
--- a/os/access.c
+++ b/os/access.c
@@ -163,6 +163,10 @@ SOFTWARE.
/* #endif */
#endif
+#if defined(IPv6) defined(AF_INET6)
+#include arpa/inet.h
+#endif
+
#endif /* WIN32 */
#define X_INCLUDE_NETDB_H
@@ -461,10 +465,6 @@ DefineSelf(int fd)
#endif
#if defined(IPv6) defined(AF_INET6)
-#include arpa/inet.h
-#endif
-
-#if defined(IPv6) defined(AF_INET6)
static void
in6_fillscopeid(struct sockaddr_in6 *sin6)
{
--
1.7.10.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11] Always initialise thread support
Hello, Couldn't pthread_once be used in order to make sure initialization happens only once? Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11] Always initialise thread support
Daniel Stone, le Fri 12 Jul 2013 22:25:38 +0100, a écrit : Make XOpenDisplay always call XInitThreads when opening a display, thus guarding it against possible disaster scenarios like calling XOpenDisplay without XInitThreads, then passing the Display pointer into an EGL library which uses threads. Or any of the other five similar failure scenarios I've seen just this week. +1. We have issues in accessibility toolkits just because they use threads to be able to work and can't manage to get XInitThreads called before the application initializes X11. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: What determines location of :0, :1 :2?
Felix Miata, le Sun 07 Jul 2013 11:05:34 -0400, a écrit : IOW, what does one need to do to ensure ttys 1-6 are not usurped by any X session, and that :0 goes to tty7, :1 to tty 8, and :2 to tty9? Simply make sure to specify the vt when starting the server: vtXX use the specified VT number Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: typing in braille
Josh Kennedy, le Sun 28 Apr 2013 15:51:09 -0400, a écrit : could you also please add the ability to use the sdfjkl keys where: s is dot 3 d is dot 2 f is dot 1 j is dot 4 k is dot 5 l is dot 6. This is already in there in plain Xorg: you can use the brai layout. You can use a key to toggle between two groups, a classical layout and the brai layout. You can then define the computer braille - text relation in .XCompose, e.g. braille_dots_1 : a braille_dots_12 : b etc. More details are available on http://brl.thefreecat.org/wiki/Xorg to use as a perkins keyboard to type computer braille and if the user wishes to write in grade2 english braille into any edit field in a desktop. grade2 input can not be done through the method above, however. One would have to implement an xim/scim/whatever module for that, which could also implement grade1 instead of doing it by hand in .XCompose. It should probably be based on liblouis to make the translation. also please add the ability to use bluetooth braille keyboards like the braillePen slim. This is rather a request for the Linux kernel, as Xorg does not manage bluetooth devices. Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Why does fbdev_drv need a console?
Hello, Christoph Theis, le Sat 06 Apr 2013 16:03:19 +0200, a écrit : So my questions are: Why would we need a console at all? Well, at least to properly support console switching to get out/into the Xserver I guess. And if a console may be required can it then be made optional? Or is there any other way to open the console somewhere else? I tried to start the X server with vtXX arguments but with no success. Did you try the -sharevts option ? That's what is supposed to be used for the usage you mentioned: I have a Raspberry Pi and want to use 2 monitors, each of them with its own X server. Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: positioning X on part of the screen ( broken LCD on old laptop )
Nikolay Kichukov, le Thu 24 Jan 2013 17:30:33 +0200, a écrit : Note: the broken part of the LCD at the top is so small, that I decided to neglect it and use full height. In that case, --fb alone should be fine, since it defaults to aligning the top-left corner. Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Michal Suchanek, le Thu 17 Jan 2013 15:26:26 +0100, a écrit : On 10 January 2013 15:27, Samuel Thibault samuel.thiba...@ens-lyon.org wrote: Michal Suchanek, le Thu 10 Jan 2013 15:20:21 +0100, a écrit : Dummy driver sets the flag because it does not need console and then the console is not open although evedev which requires console and does not set the flag is loaded later. Which is what I mentioned in yet another mail during the thread (placing the xf86OpenConsole call). Please just read mails. I don't know where the mails about that are. Definitely not in my mailbox. D'oh. Sorry about that, it seems these have not reached the mailing list indeed. Peter's suggestion 20130107040832.ga25...@yabbi.bne.redhat.com did reach the list: “ so the solution here would be to only call xf86OpenConsole() when a keyboard device comes up. on the plus side, if the evdev driver is broken this would allow you to Ctrl+C the server. On the minus side, there's a window where you can Ctrl+C the server until the device has been added. ” what didn't is my answer: “ Ok ; that still needs to be implemented, and more importantly, thoroughly tested, as in the past xf86OpenConsole() used to be done much earlier. ” Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Michal Suchanek, le Thu 10 Jan 2013 12:38:13 +0100, a écrit : a proper fix needs something like: 1) introduce a HW_OPEN_CONSOLE flag which is inverse of the HW_SKIP_CONSOLE flag 2) have all drivers but void and dummy set that - dummy has nice example of setting a flag 3) have the input hotplug code handle the flag in addition to the init code That's more or less precisely what was suggested earlier in the thread, and my precise enquiry wy earlier: which way should input drivers set the flag, since the mechanism used for video drivers does not exist for input drivers. No. What you proposed is introduce a xorg.conf option for the dummy driver to open the console. Nope. My initial proposal was the contrary. And further in the thread I proposed what I say above. In a latter post, however, you say setting up special configuration for blind users is unacceptable, and adding that option seems like a special configuraion to me. See above. That said, it's of course way simpler, instead of having to modify all drivers, to just make video-dummy and input-void set the SKIP flag, That's not going to work. If you do not set the flag in dummy the console will open whatever you set in void. The console is open on every driver probe starting with dummy. The HW_SKIP_CONSOLE hack abuses the internal knowledge of driver probing order to set the flag in the driver which is probed first but which is the wrong one for setting the flag. Re-read the source code. The console will be opened as soon as either of the drivers do not set the SKIP flag. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Michal Suchanek, le Thu 10 Jan 2013 15:20:21 +0100, a écrit : Dummy driver sets the flag because it does not need console and then the console is not open although evedev which requires console and does not set the flag is loaded later. Which is what I mentioned in yet another mail during the thread (placing the xf86OpenConsole call). Please just read mails. X server saves the flag when it's set on the first driver and opens the console when it is not set on the first driver Not on just the first driver. As of the current code state, on any video driver that does not set the SKIP flag. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Michal Suchanek, le Wed 09 Jan 2013 22:46:37 +0100, a écrit : On 9 January 2013 01:33, Samuel Thibault samuel.thiba...@ens-lyon.org wrote: Samuel Thibault, le Wed 09 Jan 2013 00:55:13 +0100, a écrit : Michal Suchanek, le Tue 08 Jan 2013 22:26:50 +0100, a écrit : Well, I hope I have made my point clear: the blind user case should get exactly the same behavior with the dummy video driver (without configuring anything else) as the 99%-standard user case, with other video drivers. I.e. a VT gets allocated, switched to, and keyboard/mouse events there go to the server. And what's the point? You don't have a screen so you don't see the VT switched. But I *NEED* the VT to be able to choose whether keyboard/mouse events go to the server or to the linux console. By switching into/out the VT, I mean. VT switching it totally irrelevant for input. From a technical point of view in the evdev case, it is irrelevant indeed. From the user point of view, it is completely relevant. It happens that X has currently only one routine that switches VT and modifies the VT mode so that only X server gets input. The two things are separate, however. Technically speaking, yes. From the user point of view, it shall be linked, otherwise he'll get lost. It is a bug that VT mode is not modified when dummy driver is used with the standard evdev driver. It is not a bug that the VT is not switched, however. Sorry, but it is an unwelcome change of behavior for blind users. In the past the server *would* switch VT. And I don't see that happening by default with the dummy driver. s/happening/coming back/ Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH RFC] xfree86: add option -notty to prevent VT allocation
Hello, Peter Hutterer, le Tue 08 Jan 2013 17:05:16 +1000, a écrit : Provided the driver permits it, Xorg -notty will not create a VT on startup. Currently this driver list includes dummy and qxl only. I'd rather call it -novt, just like -novtswitch, -sharevts, vtXX. Only the -keeptty option is really at the tty level, not the VT. This seems to do the job, it restores the original behaviour by default, but started with -notty the server skips the VT allocation provided all drivers set HW_SKIP_CONSOLE. Indeed, it looks fine for me. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Timothy Meade, le Tue 08 Jan 2013 09:53:45 -0500, a écrit : There are already distro specific configuration scripts for setting up Linux for blind user, And we should avoid them whenever possible. could they add this option when they configure the dummy output? I'm against such kind of solution. The problem is that making special configurations for blind users leads to endless issues for them to get their machine working. And it's particularly difficult for a (non-technical!) blind person to manage to do it. On the other hand, people who need to do tests such are surely technical, and most probably are able to see and understand what is happening. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Michal Suchanek, le Tue 08 Jan 2013 16:03:06 +0100, a écrit : There is already -novtswitch option. Making a corresponding -vtswitch would be simplest provided it overrides the HW_SKIP_CONSOLE override. novtswitch still allocates the VT, so it's not the same. The OP however wants the X server to DoTheRightThing(tm) automagically but there is no agreement yet what the right thing exactly is. Well, I hope I have made my point clear: the blind user case should get exactly the same behavior with the dummy video driver (without configuring anything else) as the 99%-standard user case, with other video drivers. I.e. a VT gets allocated, switched to, and keyboard/mouse events there go to the server. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Jamey Sharp, le Tue 08 Jan 2013 10:39:35 -0800, a écrit : I would very much like it if people could continue to run Xorg in Xnest/Xvfb-like situations without needing extra privileges I agree or magic flags. I just have to disagree on making the use of the dummy video driver any more complex at all for the non-technical blind people. As an answer, as I proposed in the #681781 Debian bugs report (http://bugs.debian.org/681781), Xorg could simply provide an Xdumb script which makes use of all the needed magic flags and configuration to run an Xnest/Xvfb-like server. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Michal Suchanek, le Tue 08 Jan 2013 22:26:50 +0100, a écrit : Well, I hope I have made my point clear: the blind user case should get exactly the same behavior with the dummy video driver (without configuring anything else) as the 99%-standard user case, with other video drivers. I.e. a VT gets allocated, switched to, and keyboard/mouse events there go to the server. And what's the point? You don't have a screen so you don't see the VT switched. But I *NEED* the VT to be able to choose whether keyboard/mouse events go to the server or to the linux console. The driver does not render anything so does not need allocate a VT. The *video* driver don't. The *input* driver do. And in this situation the user will expect that to happen, just like it does when a screen is plugged. That's just plain dumb requirement and defeats the purpose of dummy as non-privileged X driver and non-disturbing test driver. The dummy driver is a *video* driver, not an *input* driver. If you want non-privileged X, you also need to use a non-privileged input driver. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Samuel Thibault, le Wed 09 Jan 2013 00:55:13 +0100, a écrit : Michal Suchanek, le Tue 08 Jan 2013 22:26:50 +0100, a écrit : Well, I hope I have made my point clear: the blind user case should get exactly the same behavior with the dummy video driver (without configuring anything else) as the 99%-standard user case, with other video drivers. I.e. a VT gets allocated, switched to, and keyboard/mouse events there go to the server. And what's the point? You don't have a screen so you don't see the VT switched. But I *NEED* the VT to be able to choose whether keyboard/mouse events go to the server or to the linux console. By switching into/out the VT, I mean. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Michal Suchanek, le Sat 05 Jan 2013 18:55:28 +0100, a écrit : On 5 January 2013 02:10, Samuel Thibault sthiba...@debian.org wrote: Alan Coopersmith, le Mon 31 Dec 2012 17:46:47 -0800, a écrit : On 12/31/12 05:36 PM, Samuel Thibault wrote: Michal Suchanek, le Mon 31 Dec 2012 19:22:13 +0100, a écrit : why is that patch needed? It is quite non-obvious why would dummy driver require a console under any circumstances. It does not render anything anywhere so does not use console for anything. The console *is* needed for keyboard input. Again, the use case is blind people who have use of possessing an actual screen, and thus don't have any, and thus have to use the dummy driver. So it sounds like that should be handled by the input driver, not the output driver. Ok, that makes sense. Input drivers however don't currently have a way to request the core to callxf86OpenConsole, similar to the absence of the HW_SKIP_CONSOLE flag in the case of video drivers. What do you recommend to add to the InputDriverRec? A driverFunc method like video drivers? Something else? I still don't understand the problem. The evdev driver opens the evdev device when loaded and reads input there. That happens even with dummy video driver so long as you do not carefully prevent the evdev driver from loading, does it not? It does not. See for instance the attached xorg.conf, then I run from vt1 xinit /usr/bin/fvwm -- :1 there is no VT switch, and pressing ^C 5s later kills the server (while we'd want ^C to just go to the server). The resulting Xorg.1.log is attached. What I understand is that evedev does open things, but since no VT was allocated, the evdev driver does not eat keypresses, i.e. from its point of view it's as if we had switched away from an allocated VT. So what Alan suggested is that the evdev driver simply tells the core that it needs a VT to work properly. I'm now just asking which way that should be done. Samuel Section InputDevice Identifier Generic Keyboard Driver evdev Option XkbModel geniuskb19e Option XkbLayout fr,brai Option XkbVariantoss, Option XkbOptions compose:lwin,compose:rwin,nbsp:level3n,grp:shift_caps_toggle EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/gpmdata Option Protocol IntelliMouse Option Emulate3Buttons true EndSection Section Device Identifier Configured Video Device Driver dummy EndSection Section Monitor Identifier Configured Monitor EndSection [ 66121.842] X.Org X Server 1.12.4 Release Date: 2012-08-27 [ 66121.846] X Protocol Version 11, Revision 0 [ 66121.847] Build Operating System: Linux 3.2.0-4.drm-amd64 x86_64 Debian [ 66121.849] Current Operating System: Linux type 3.7.0 #2 SMP Fri Dec 21 01:14:41 CET 2012 x86_64 [ 66121.849] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0 root=UUID=38e6e493-2f5f-4a98-b1d6-a9434f0683cc ro [ 66121.851] Build Date: 29 November 2012 07:18:16PM [ 66121.852] xorg-server 2:1.12.4-4 (Julien Cristau jcris...@debian.org) [ 66121.853] Current version of pixman: 0.26.0 [ 66121.858]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 66121.858] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 66121.863] (==) Log file: /var/log/Xorg.1.log, Time: Sat Jan 5 19:00:53 2013 [ 66121.871] (==) Using config file: /etc/X11/xorg.conf [ 66121.873] (==) Using system config directory /usr/share/X11/xorg.conf.d [ 66121.876] (==) No Layout section. Using the first Screen section. [ 66121.876] (==) No screen section available. Using defaults. [ 66121.876] (**) |--Screen Default Screen Section (0) [ 66121.876] (**) | |--Monitor default monitor [ 66121.876] (==) No device specified for screen Default Screen Section. Using the first device section listed. [ 66121.876] (**) | |--Device Configured Video Device [ 66121.876] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [ 66121.876] (==) Automatically adding devices [ 66121.876] (==) Automatically enabling devices [ 66121.896] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/cyrillic, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins [ 66121.896] (==) ModulePath set to /usr
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Michal Suchanek, le Sat 05 Jan 2013 22:47:20 +0100, a écrit : there is no VT switch, and pressing ^C 5s later kills the server (while we'd want ^C to just go to the server). The resulting Xorg.1.log is attached. I don't think that an actual VT switch is required From the point of the user, it is. There is no reason why it should not happen just like with other video drivers in the use case at stake. It would be quite a few drivers to modify We can proceed just like video devices: only modify the void input driver into saying it doesn't need a VT, and the core then avoids allocating a VT only if *only* the dummy video driver and void input driver are used. On x86 there is always the ACPI button but on some platforms nothing like that is present so this flag would have to be set dynamically when an input device is plugged in if set bu the input driver. Also evdev handles keyboards and mice. Is plugging in a mouse enough to warrant locking the tty? Is presence of synaptics or wacom device? I'm surprised that the discussion ends up with this way of thinking: shouldn't it be the converse, i.e. a VT is always allocated *except* if that is explicitly asked for by a special configuration? Otherwise we'll keep having users saying that their special use does not trigger a VT allocation... Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Michal Suchanek, le Sat 05 Jan 2013 23:44:39 +0100, a écrit : On 5 January 2013 23:04, Samuel Thibault sthiba...@debian.org wrote: Michal Suchanek, le Sat 05 Jan 2013 22:47:20 +0100, a écrit : there is no VT switch, and pressing ^C 5s later kills the server (while we'd want ^C to just go to the server). The resulting Xorg.1.log is attached. I don't think that an actual VT switch is required From the point of the user, it is. There is no reason why it should not happen just like with other video drivers in the use case at stake. Those video drivers render graphics. The dummy driver does not. But input drivers are still the same. It's not the same case. From the user point of view it is: the user simply does not have a screen to plug to his computer, and does not need any, anway, but the use case is *exactly* the same: a user sitting in front of his computer, wants to start an X session. It would be quite a few drivers to modify We can proceed just like video devices: only modify the void input driver into saying it doesn't need a VT, and the core then avoids allocating a VT only if *only* the dummy video driver and void input driver are used. Indeed, you could possibly say that the dummy driver does not need video output which then requires a VT switch and the void driver does not need a tty input which would require locking the tty. The former is already done (and is the whole reason why it broke things for blind people). I'm asking which way is recommended to do the latter. On x86 there is always the ACPI button but on some platforms nothing like that is present so this flag would have to be set dynamically when an input device is plugged in if set bu the input driver. Also evdev handles keyboards and mice. Is plugging in a mouse enough to warrant locking the tty? Is presence of synaptics or wacom device? I'm surprised that the discussion ends up with this way of thinking: shouldn't it be the converse, i.e. a VT is always allocated *except* if that is explicitly asked for by a special configuration? Otherwise we'll keep having users saying that their special use does not trigger a VT allocation... But there is the problem. The dummy driver sets the flag because it does not need the tty. The evdev driver does need the tty but it has no flag to set because opening a tty is the default. The bug comes exactly from the thinking that switching tty is the default and only an exception to this rule is flagged. It has been so for decades. It's hard to call that a bug. It would be much saner for the driver to say that it needs the tty if and when it needs it. But as was mentioned, it'd mean patching *all* drivers, since it's a behavior change. Thus the proposition of continuing the same way as was done with video devices: not tell in which case it's needed, but in which cases it's *not* needed. Now, about the when it needs it, unfortunately it's not so simple ATM: the core opens the console just once in InitOutput. I'm a bit afraid of moving that (and conversely, the dontVTSwitch flag) somewhere else to make it dynamic: who knows what subtle bug that might introduce. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: support for HW_SKIP_CONSOLE breaks use by blind people
Alan Coopersmith, le Mon 31 Dec 2012 17:46:47 -0800, a écrit : On 12/31/12 05:36 PM, Samuel Thibault wrote: Michal Suchanek, le Mon 31 Dec 2012 19:22:13 +0100, a écrit : why is that patch needed? It is quite non-obvious why would dummy driver require a console under any circumstances. It does not render anything anywhere so does not use console for anything. The console *is* needed for keyboard input. Again, the use case is blind people who have use of possessing an actual screen, and thus don't have any, and thus have to use the dummy driver. So it sounds like that should be handled by the input driver, not the output driver. Ok, that makes sense. Input drivers however don't currently have a way to request the core to callxf86OpenConsole, similar to the absence of the HW_SKIP_CONSOLE flag in the case of video drivers. What do you recommend to add to the InputDriverRec? A driverFunc method like video drivers? Something else? Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] support for HW_SKIP_CONSOLE breaks use by blind people
Michal Suchanek, le Mon 31 Dec 2012 19:22:13 +0100, a écrit : why is that patch needed? It is quite non-obvious why would dummy driver require a console under any circumstances. It does not render anything anywhere so does not use console for anything. The console *is* needed for keyboard input. Again, the use case is blind people who have use of possessing an actual screen, and thus don't have any, and thus have to use the dummy driver. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Bug#696965: support for HW_SKIP_CONSOLE breaks use by blind people
Package: xserver-xorg-video-dummy
Version: 1:0.3.3-2
Severity: important
Tags: upstream
Hello,
Unfortunately I've gotten the bug report only now...
In upstream commit e39d9a26
@@ -801,7 +804,7 @@ dummyDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op,
pointer ptr)
+ (*flag) = HW_SKIP_CONSOLE;
This has broken the use of Xorg by blind people who don't have a screen:
since drivers tend to abort when no screen is connected, blind people
would use the dummy driver. But now that the dummy driver itself tells
not to open the console, keypresses are not eaten by the Xorg server,
thus making the whole Xorg session completely unusable.
What was the rationale for the change? I can understand that in some
situation people would not want to open the console, but I would have
rather made it an option, and have made it not enabled by default,
because the blind people who need the dummy driver do not necessarily
have much technical knowledge beyond use the dummy driver, while
people who want to use the dummy driver with no VT most probably
understand what that means, and would be able to enable the option.
This was unfortunately actually already shipped in Squeeze. The attached
patch can be used by people for now to avoid the issue, I'll work on
adding an option upstream.
Samuel
commit 1ec9d5adaf753715b78377483a3a2d71a323d43e
Author: Samuel Thibault samuel.thiba...@ens-lyon.org
Date: Sun Dec 30 00:58:51 2012 +0100
Revert Add support for HW_SKIP_CONSOLE
This reverts commit e39d9a265572c273915f1803a729e7211d7b247b.
diff --git a/src/dummy_driver.c b/src/dummy_driver.c
index 6062c39..566a006 100644
--- a/src/dummy_driver.c
+++ b/src/dummy_driver.c
@@ -801,9 +801,6 @@ DUMMYCreateWindow(WindowPtr pWin)
return TRUE;
}
-#ifndef HW_SKIP_CONSOLE
-#define HW_SKIP_CONSOLE 4
-#endif
static Bool
dummyDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op, pointer ptr)
@@ -813,7 +810,7 @@ dummyDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op,
pointer ptr)
switch (op) {
case GET_REQUIRED_HW_INTERFACES:
flag = (CARD32*)ptr;
- (*flag) = HW_SKIP_CONSOLE;
+ (*flag) = 0;
return TRUE;
default:
return FALSE;
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] support for HW_SKIP_CONSOLE breaks use by blind people
Control: tags 696965 + patch
Hello,
Samuel Thibault, le Sun 30 Dec 2012 01:07:47 +0100, a écrit :
I would have rather made it an option, and have made it not enabled
by default, because the blind people who need the dummy driver do
not necessarily have much technical knowledge beyond use the dummy
driver, while people who want to use the dummy driver with no VT most
probably understand what that means, and would be able to enable the
option.
Here is a patch proposal.
Samuel
Add OpenConsole option to dummy devices
This permits to choose whether the dummy device wants the console. The
driver will make the core open the console if at least one device wants
it.
Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org
diff --git a/src/dummy_driver.c b/src/dummy_driver.c
index 6062c39..0ec5f4b 100644
--- a/src/dummy_driver.c
+++ b/src/dummy_driver.c
@@ -118,11 +118,13 @@ static SymTabRec DUMMYChipsets[] = {
};
typedef enum {
-OPTION_SW_CURSOR
+OPTION_SW_CURSOR,
+OPTION_OPEN_CONSOLE
} DUMMYOpts;
static const OptionInfoRec DUMMYOptions[] = {
{ OPTION_SW_CURSOR,SWcursor, OPTV_BOOLEAN, {0}, FALSE },
+{ OPTION_OPEN_CONSOLE, OpenConsole, OPTV_BOOLEAN, {0}, FALSE },
{ -1, NULL, OPTV_NONE, {0}, FALSE }
};
@@ -812,9 +814,36 @@ dummyDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op,
pointer ptr)
switch (op) {
case GET_REQUIRED_HW_INTERFACES:
+ {
+ Bool OpenConsole = FALSE;
+ GDevPtr *devSections;
+ int numDevSections, i;
+
+ /*
+* Find the config file Device sections that match this
+* driver
+*/
+ numDevSections = xf86MatchDevice(DUMMY_DRIVER_NAME, devSections);
+
+ for (i = 0; i numDevSections; i++) {
+ OptionInfoPtr Options;
+
+ if ((Options = malloc(sizeof(DUMMYOptions
+ {
+ Bool DeviceOpenConsole = TRUE;
+ memcpy(Options, DUMMYOptions, sizeof(DUMMYOptions));
+ xf86ProcessOptions(-1, devSections[i]-options, Options);
+ xf86GetOptValBool(Options, OPTION_OPEN_CONSOLE,
DeviceOpenConsole);
+ if (DeviceOpenConsole)
+ OpenConsole = TRUE;
+ free(Options);
+ }
+ }
+
flag = (CARD32*)ptr;
- (*flag) = HW_SKIP_CONSOLE;
+ (*flag) = OpenConsole ? 0 : HW_SKIP_CONSOLE;
return TRUE;
+ }
default:
return FALSE;
}
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: tablet as a second monitor on linux
Adam GROSZER, le Wed 19 Dec 2012 12:35:07 +0100, a écrit : On 12/19/2012 10:52 AM, Samuel Thibault wrote: Adam GROSZER, le Wed 19 Dec 2012 09:21:12 +0100, a écrit : The question is, how to create the secondary headless virtual monitor with X. I'm lost there. You can probably use the dummy X driver for that. You mind shedding some light on how to create that virtual screen? You'll have to write device xorg.conf sections by hand. I'm sorry, I'm not an X expert. Nobody really is. It's just a matter of taking the time to look at what you need, here an xorg.conf tutorial. Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[PATCH libpciaccess] Implement legacy io map for x86 backend
Add the legacy io and map methods for the x86 backend, using ioperm,
in/out, and the existing mmap method.
Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org
---
src/x86_pci.c | 100 -
1 file changed, 99 insertions(+), 1 deletion(-)
diff --git a/src/x86_pci.c b/src/x86_pci.c
index 78e5f6c..c75242e 100644
--- a/src/x86_pci.c
+++ b/src/x86_pci.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2009, 2012 Samuel Thibault
+ * Copyright (c) 2009, 2012 Samuel Thibault
* Heavily inspired from the freebsd, netbsd, and openbsd backends
* (C) Copyright Eric Anholt 2006
* (C) Copyright IBM Corporation 2006
@@ -550,6 +550,94 @@ pci_system_x86_destroy(void)
x86_disable_io();
}
+static struct pci_io_handle *
+pci_device_x86_open_legacy_io(struct pci_io_handle *ret,
+struct pci_device *dev, pciaddr_t base, pciaddr_t size)
+{
+x86_enable_io();
+
+ret-base = base;
+ret-size = size;
+
+return ret;
+}
+
+static void
+pci_device_x86_close_io(struct pci_device *dev, struct pci_io_handle *handle)
+{
+/* Like in the Linux case, do not disable I/O, as it may be opened several
+ * times, and closed fewer times. */
+/* x86_disable_io(); */
+}
+
+static uint32_t
+pci_device_x86_read32(struct pci_io_handle *handle, uint32_t reg)
+{
+return inl(reg + handle-base);
+}
+
+static uint16_t
+pci_device_x86_read16(struct pci_io_handle *handle, uint32_t reg)
+{
+return inw(reg + handle-base);
+}
+
+static uint8_t
+pci_device_x86_read8(struct pci_io_handle *handle, uint32_t reg)
+{
+return inb(reg + handle-base);
+}
+
+static void
+pci_device_x86_write32(struct pci_io_handle *handle, uint32_t reg,
+ uint32_t data)
+{
+outl(data, reg + handle-base);
+}
+
+static void
+pci_device_x86_write16(struct pci_io_handle *handle, uint32_t reg,
+ uint16_t data)
+{
+outw(data, reg + handle-base);
+}
+
+static void
+pci_device_x86_write8(struct pci_io_handle *handle, uint32_t reg,
+ uint8_t data)
+{
+outb(data, reg + handle-base);
+}
+
+static int
+pci_device_x86_map_legacy(struct pci_device *dev, pciaddr_t base,
+pciaddr_t size, unsigned map_flags, void **addr)
+{
+struct pci_device_mapping map;
+int err;
+
+map.base = base;
+map.size = size;
+map.flags = map_flags;
+err = pci_device_x86_map_range(dev, map);
+*addr = map.memory;
+
+return err;
+}
+
+static int
+pci_device_x86_unmap_legacy(struct pci_device *dev, void *addr,
+pciaddr_t size)
+{
+struct pci_device_mapping map;
+
+map.size = size;
+map.flags = 0;
+map.memory = addr;
+
+return pci_device_generic_unmap_range(dev, map);
+}
+
static const struct pci_system_methods x86_pci_methods = {
.destroy = pci_system_x86_destroy,
.read_rom = pci_device_x86_read_rom,
@@ -559,6 +647,16 @@ static const struct pci_system_methods x86_pci_methods = {
.read = pci_device_x86_read,
.write = pci_device_x86_write,
.fill_capabilities = pci_fill_capabilities_generic,
+.open_legacy_io = pci_device_x86_open_legacy_io,
+.close_io = pci_device_x86_close_io,
+.read32 = pci_device_x86_read32,
+.read16 = pci_device_x86_read16,
+.read8 = pci_device_x86_read8,
+.write32 = pci_device_x86_write32,
+.write16 = pci_device_x86_write16,
+.write8 = pci_device_x86_write8,
+.map_legacy = pci_device_x86_map_legacy,
+.unmap_legacy = pci_device_x86_unmap_legacy,
};
static int pci_probe(struct pci_system_x86 *pci_sys_x86)
--
1.7.10
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: KeySym to Unicode?
Troy Watson, le Wed 25 Jan 2012 18:55:37 +1000, a écrit : Thanks for the reply - Is that what I want though? Looking at http://www.x.org/releases/current/doc/man/man3/XkbTranslateKeySym.3.xhtml it returns me a KeySym See the text: it takes a keysym, and returns another one if the keyboard state is supposed to change it. and a char buffer filled with... something. Which is the best description of the keysym you can imagine. I just want a keysym-unicode code point conversion. Convert the string to unicode then. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: KeySym to Unicode?
Troy Watson, le Tue 24 Jan 2012 17:36:10 +1000, a écrit : Does there exist a function in Xlib as simple as this... wchar_t unicode = XKeySymToUnicode( KeySym ) ...to map a KeySym to it's Unicode eqivilent? If not, why? What's available to achieve similar results? XkbTranslateKeySym? Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL] xserver: enable TLS even if AIGLX is not enabled
Keith, Please pull the changes below to fix software-rastered aiglx on non-dri systems. Thanks, Samuel The following changes since commit be3be7580b6f6fd2f7fa4d4abfe5e1ab19470223: Merge remote branch 'ajax/for-keithp' (2011-01-20 21:21:21 -0800) are available in the git repository at: git://people.freedesktop.org/~sthibaul/xserver-hurd.git master-hurd-aiglx Samuel Thibault (1): xserver: enable TLS even if AIGLX is not enabled configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL] hurd: Fix use of deprecated iopl device
Keith, Please pull the changes below to fix Xorg with mainstream gnumach. Samuel The following changes since commit 1a0d9324b3d9fd93e685066e0e5cea0611878c0d: Revert Set DamageSetReportAfterOp to true for the damage extension (#30260) (2010-10-20 16:49:14 -0700) are available in the git repository at: git://people.freedesktop.org/~sthibaul/xserver-hurd.git master-iopl Samuel Thibault (1): hurd: Fix use of deprecated iopl device hw/xfree86/os-support/hurd/hurd_mmap.c | 12 ++-- hw/xfree86/os-support/hurd/hurd_video.c | 18 +- 2 files changed, 15 insertions(+), 15 deletions(-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Do not trap access to timer and keyboard
Adam Jackson, le Fri 19 Mar 2010 14:29:55 -0400, a écrit : Well in that case, the ioperm() is definitely bogus on all platforms, since all it can do is make us crash. But it indicates that the int10 wrapper needs to do a better job of emulating those ports, since the kernel is definitely going to be using them. Could we at least apply the patch below to fix mga-g450? Samuel commit 9d14b2727078837a2e4c8a9e61ec2ac0b39f008f Author: Samuel Thibault samuel.thiba...@ens-lyon.org Date: Sat Mar 13 01:49:47 2010 +0100 Disable timer/keyboard trapping on GNU/Hurd for now Trapping disabled for now, as some VBIOSes (mga-g450 notably) use these ports, and the int10 wrapper is not emulating them. It's effectively what happens in the Linux variant too, as iopl() is used there, making the ioperm() meaningless. Signed-off-by: Olaf Buddenhagen ant...@users.sf.net Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org diff --git a/hw/xfree86/os-support/hurd/hurd_video.c b/hw/xfree86/os-support/hurd/hurd_video.c index 4a99db3..ff4557f 100644 --- a/hw/xfree86/os-support/hurd/hurd_video.c +++ b/hw/xfree86/os-support/hurd/hurd_video.c @@ -124,8 +124,17 @@ xf86EnableIO() FatalError(xf86EnableIO: ioperm() failed (%s)\n, strerror(errno)); return FALSE; } +#if 0 +/* + * Trapping disabled for now, as some VBIOSes (mga-g450 notably) use these + * ports, and the int10 wrapper is not emulating them. (Note that it's + * effectively what happens in the Linux variant too, as iopl() is used + * there, making the ioperm() meaningless.) + * + * Reenable this when int10 gets fixed. */ ioperm(0x40,4,0); /* trap access to the timer chip */ ioperm(0x60,4,0); /* trap access to the keyboard controller */ +#endif return TRUE; } diff --git a/hw/xfree86/os-support/linux/lnx_video.c b/hw/xfree86/os-support/linux/lnx_video.c index b97757c..39c728d 100644 --- a/hw/xfree86/os-support/linux/lnx_video.c +++ b/hw/xfree86/os-support/linux/lnx_video.c @@ -530,6 +530,8 @@ xf86EnableIO(void) return FALSE; } # if !defined(__alpha__) + /* XXX: this is actually not trapping anything because of iopl(3) +* above */ ioperm(0x40,4,0); /* trap access to the timer chip */ ioperm(0x60,4,0); /* trap access to the keyboard controller */ # endif ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH,HURD] Fix use of deprecated iopl device
This fixes Xserver on GNU/Hurd into using the mem device instead of
the deprecated iopl device.
Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org
diff --git a/hw/xfree86/os-support/hurd/hurd_mmap.c
b/hw/xfree86/os-support/hurd/hurd_mmap.c
index ccef5f2..3f942aa 100644
--- a/hw/xfree86/os-support/hurd/hurd_mmap.c
+++ b/hw/xfree86/os-support/hurd/hurd_mmap.c
@@ -39,8 +39,8 @@
int
xf86ReadBIOS(unsigned long Base,unsigned long Offset,unsigned char *Buf,int
Len)
{
-mach_port_t device,iopl_dev;
-memory_object_t iopl_mem;
+mach_port_t device,mem_dev;
+memory_object_t mem_obj;
vm_address_t addr = (vm_address_t)0; /* serach starting address */
kern_return_t err;
@@ -51,14 +51,14 @@ xf86ReadBIOS(unsigned long Base,unsigned long
Offset,unsigned char *Buf,int Len)
errno = err;
FatalError(xf86ReadBIOS() can't get_privileged_ports.
(%s)\n,strerror(errno));
}
-err = device_open(device,D_READ|D_WRITE,iopl,iopl_dev);
+err = device_open(device,D_READ|D_WRITE,mem,mem_dev);
mach_port_deallocate (mach_task_self (), device);
if( err )
{
errno = err;
FatalError(xf86ReadBIOS() can't device_open. (%s)\n,strerror(errno));
}
-err = device_map(iopl_dev,VM_PROT_READ|VM_PROT_WRITE, Base , BIOS_SIZE
,iopl_mem,0);
+err = device_map(mem_dev,VM_PROT_READ|VM_PROT_WRITE, Base , BIOS_SIZE
,mem_obj,0);
if( err )
{
errno = err;
@@ -69,13 +69,13 @@ xf86ReadBIOS(unsigned long Base,unsigned long
Offset,unsigned char *Buf,int Len)
BIOS_SIZE,
0,
TRUE,
-iopl_mem,
+mem_obj,
Base,
FALSE,
VM_PROT_READ|VM_PROT_WRITE,
VM_PROT_READ|VM_PROT_WRITE,
VM_INHERIT_SHARE);
-mach_port_deallocate(mach_task_self(),iopl_mem);
+mach_port_deallocate(mach_task_self(),mem_obj);
if( err )
{
errno = err;
diff --git a/hw/xfree86/os-support/hurd/hurd_video.c
b/hw/xfree86/os-support/hurd/hurd_video.c
index 4a99db3..3d7af40 100644
--- a/hw/xfree86/os-support/hurd/hurd_video.c
+++ b/hw/xfree86/os-support/hurd/hurd_video.c
@@ -44,8 +44,8 @@
static pointer
mapVidMem(int ScreenNum, unsigned long Base, unsigned long Size, int Flags)
{
-mach_port_t device,iopl_dev;
-memory_object_t iopl_mem;
+mach_port_t device,mem_dev;
+memory_object_t mem_obj;
kern_return_t err;
vm_address_t addr=(vm_address_t)0;
@@ -55,7 +55,7 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned long
Size, int Flags)
errno = err;
FatalError(xf86MapVidMem() can't get_privileged_ports.
(%s)\n,strerror(errno));
}
-err = device_open(device,D_READ|D_WRITE,iopl,iopl_dev);
+err = device_open(device,D_READ|D_WRITE,mem,mem_dev);
mach_port_deallocate (mach_task_self(), device);
if( err )
{
@@ -63,7 +63,7 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned long
Size, int Flags)
FatalError(xf86MapVidMem() can't device_open. (%s)\n,strerror(errno));
}
-err = device_map(iopl_dev,VM_PROT_READ|VM_PROT_WRITE, Base , Size
,iopl_mem,0);
+err = device_map(mem_dev,VM_PROT_READ|VM_PROT_WRITE, Base , Size
,mem_obj,0);
if( err )
{
errno = err;
@@ -74,23 +74,23 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned long
Size, int Flags)
Size,
0, /* mask */
TRUE, /* anywhere */
-iopl_mem,
+mem_obj,
(vm_offset_t)Base,
FALSE, /* copy on write */
VM_PROT_READ|VM_PROT_WRITE,
VM_PROT_READ|VM_PROT_WRITE,
VM_INHERIT_SHARE);
-mach_port_deallocate(mach_task_self(),iopl_mem);
+mach_port_deallocate(mach_task_self(),mem_obj);
if( err )
{
errno = err;
- FatalError(xf86MapVidMem() can't vm_map.(iopl_mem)
(%s)\n,strerror(errno));
+ FatalError(xf86MapVidMem() can't vm_map.(mem_obj)
(%s)\n,strerror(errno));
}
-mach_port_deallocate(mach_task_self(),iopl_dev);
+mach_port_deallocate(mach_task_self(),mem_dev);
if( err )
{
errno = err;
- FatalError(xf86MapVidMem() can't mach_port_deallocate.(iopl_dev)
(%s)\n,strerror(errno));
+ FatalError(xf86MapVidMem() can't mach_port_deallocate.(mem_dev)
(%s)\n,strerror(errno));
}
return (pointer)addr;
}
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xserver: Enable visible cursor on start without -retro #26798
Dave Airlie, le Thu 21 Oct 2010 12:10:14 +1000, a écrit : On Wed, Oct 20, 2010 at 9:23 AM, Samuel Thibault samuel.thiba...@ens-lyon.org wrote: Not having a visible cursor by default poses problems with a lot of users: when they are faced with a completely dark screen without even a moving mouse, they think their machine is completely hung, while it could just be that X clients can't connect or are not starting for some reason. NAK on the this needs discussion grounds. Seems like this was the whole point of the retro stuff in the first place, to not display a cursor and not draw a background. Well, I can understand that not drawing a background is nicer looking. But not showing a cursor really apparently really is a pain for the user. I _keep_ getting user feedback about my X server is hung, and Xorg.0.log posts which of course don't contain fatal error messages, frustrated users etc. While the problem often simply is that the user doesn't have xauth, or such... See https://bugs.freedesktop.org/show_bug.cgi?id=26798 Really, not having a cursor poses a real problem: users assuming wrong things (and I wouldn't even dream a user wondering what if I passed that -retro thing to get back into the 1988 to check whether it's really the X server that hangs, it just won't ever happen). While having a cross-cursor for a few seconds... Is it really _so_ ugly that we want to get those bug reports? Frankly enough, I think I'll be thick-headed enough to report on this thread for each user report having the same issue as mentioned above, just like I did 5 times already since February (and I'm just talking about Hurd user reports, i.e. an extremely small part of the Xorg users). Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xserver: Enable visible cursor on start without -retro #26798
Not having a visible cursor by default poses problems with a lot of users: when
they are faced with a completely dark screen without even a moving mouse, they
think their machine is completely hung, while it could just be that X clients
can't connect or are not starting for some reason.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=26798
Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org
diff --git a/doc/Xserver.man.pre b/doc/Xserver.man.pre
index ce3b3a1..9a93d12 100644
--- a/doc/Xserver.man.pre
+++ b/doc/Xserver.man.pre
@@ -208,9 +208,8 @@ turns off auto-repeat.
turns on auto-repeat.
.TP 8
.B -retro
-starts the stipple with the classic stipple and cursor visible. The default
-is to start with a black root window, and to suppress display of the cursor
-until the first time an application calls XDefineCursor(). For the Xorg
+starts the stipple with the classic stipple. The default
+is to start with a black root window. For the Xorg
server, this also sets the default for the DontZap option to FALSE. For
kdrive servers, this implies -zap.
.TP 8
diff --git a/os/utils.c b/os/utils.c
index 51455cc..0b03deb 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -509,7 +509,7 @@ void UseMsg(void)
ErrorF(-r turns off auto-repeat\n);
ErrorF(r turns on auto-repeat \n);
ErrorF(-render [default|mono|gray|color] set render color alloc
policy\n);
-ErrorF(-retro start with classic stipple and cursor\n);
+ErrorF(-retro start with classic stipple\n);
ErrorF(-s # screen-saver timeout (minutes)\n);
ErrorF(-t # default pointer threshold (pixels/t)\n);
ErrorF(-terminate terminate at server reset\n);
diff --git a/xfixes/cursor.c b/xfixes/cursor.c
index 41ba0fb..22477ff 100644
--- a/xfixes/cursor.c
+++ b/xfixes/cursor.c
@@ -1034,8 +1034,7 @@ XFixesCursorInit (void)
{
inti;
-if (party_like_its_1989)
- CursorVisible = EnableCursor;
+CursorVisible = EnableCursor;
if (!dixRegisterPrivateKey(CursorScreenPrivateKeyRec, PRIVATE_SCREEN, 0))
return FALSE;
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Translating/localizing X.Org apps
Hello, Alan Coopersmith, le Sun 26 Sep 2010 13:04:27 -0700, a écrit : Is there any interest in the community for actually having these localized, or are we happy with telling users of non-english locales to use the localized equivalents from GNOME/KDE/etc.? I am interested, and already raised the issue some time ago: http://lists.debian.org/debian-i18n/2006/08/msg00196.html also see the whole thread on http://lists.freedesktop.org/archives/xorg/2006-August/017583.html If there is interest, does anyone want to volunteer to figure out what we need to do to hook these up with the Translation Project ( http://translationproject.org/ )? That probably requires minor knowledge of Makefile.am editing, but not knowledge of the internals of any of the software packages in question. It's rather resource2po and po2resource scripts that are needed, to be able to feed the translation project with their usual .po format. I believe most of the Xaw-based apps should support app-defaults translations, but don't know if the translation project accepts those directly or wants .po files generated for translation. They'd really rather like .po files since they have a whole toolchain to handle translations updates. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] use CLOCK_MONOTONIC_COARSE posix timer instead of CLOCK_MONOTONIC in Xorg
Daniel Stone, le Tue 24 Aug 2010 14:46:24 +1000, a écrit : Do we need to consider the above scenario? If the above scenario doesn't need to be cared, I will update the patch to assure that the CLOCK_MONOTONIC_COARSE posix timer will be tried only when there exists the corresponding definition. Why not just fix glibc to include the definition? It's there already of course. But you won't see it appearing in distribution before some time. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] use CLOCK_MONOTONIC_COARSE posix timer instead of CLOCK_MONOTONIC in Xorg
ykzhao, le Tue 24 Aug 2010 15:55:41 +0800, a écrit : b. CLOCK_MONOTONIC_COARSE is already defined. But the corresponding id is not 6. That won't happen on Linux, the value is now cast into stone. That's why it's safe to use #ifdef __linux__ # ifndef CLOCK_MONOTONIC_COARSE # define CLOCK_MONOTONIC_COARSE 6 # endif #endif On other OSes that may happen (that's the original Nack against your patch), thus the #ifdef __linux__ above is necessary. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] use CLOCK_MONOTONIC_COARSE posix timer instead of CLOCK_MONOTONIC in Xorg
ykzhao, le Tue 24 Aug 2010 08:32:48 +0800, a écrit : On Mon, 2010-08-23 at 23:25 +0800, Adam Jackson wrote: On Mon, 2010-08-23 at 10:23 +0200, Mark Kettenis wrote: From: yakui.z...@intel.com Date: Mon, 23 Aug 2010 15:20:05 +0800 From: Zhao Yakui yakui.z...@intel.com --- os/utils.c | 14 +- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/os/utils.c b/os/utils.c index 51455cc..a08d591 100644 --- a/os/utils.c +++ b/os/utils.c @@ -242,6 +242,10 @@ OsSignal(int sig, OsSigHandlerPtr handler) #endif #endif +#ifndef CLOCK_MONOTONIC_COARSE +#define CLOCK_MONOTONIC_COARSE 6 +#endif What if an OS doesn't have CLOCK_MONOTONIC_COARSE, but uses the clock ID 6 for some other purpose? Then this patch would be wrong. NAK on that basis. Yes. Agree. How about using the constant value(6) directly? Err, you must be kidding... #ifdef __linux__ # ifndef CLOCK_MONOTONIC_COARSE # define CLOCK_MONOTONIC_COARSE 6 # endif #endif should however be fine. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] use CLOCK_MONOTONIC_COARSE posix timer instead of CLOCK_MONOTONIC in Xorg
ykzhao, le Tue 24 Aug 2010 09:07:49 +0800, a écrit :
+static clockid_t clockid;
+if (!clockid) {
+#ifdef __linux__
+#ifndef CLOCK_MONONOTIC_COARSE
+#define CLOCK_MONOTONIC_COARSE
If you don't provide the value 6 here, it's completely useless.
+#endif
+ if ((clock_getres(CLOCK_MONOTONIC_COARSE, tp) == 0)
Samuel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH,HURD] Fix use of deprecated iopl device
olafbuddenha...@gmx.net, le Sat 14 Aug 2010 23:15:01 +0200, a écrit : On Fri, Aug 13, 2010 at 12:37:22PM +0200, Samuel Thibault wrote: olafbuddenha...@gmx.net, le Tue 10 Aug 2010 00:02:58 +0200, a écrit : -mach_port_t device,iopl_dev; -memory_object_t iopl_mem; +mach_port_t device,mem_dev; +memory_object_t mem_mem; mem_mem is a rather weird variable name. Perhaps you could rename it to something clearer? Maybe mem_object... Well, from the point of view of Xorg, it is a device which gets mapped, even if inside gnumach it is called an object. Not sure what you mean. A Mach device (mem_dev in this case) can't be mappend directly. You have to obtain a memory object (mem_mem) which you can map. In this case we have memory object that describes the physical RAM -- so the first mem and the second mem in this variable name describe two completely different things... To be honest, I truly don't care about the name at all. All I do care about is to get the patch commited eventually. So give us the variable names that shall be good and let's be done with it. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH,HURD] Fix use of deprecated iopl device
olafbuddenha...@gmx.net, le Tue 10 Aug 2010 00:02:58 +0200, a écrit : -mach_port_t device,iopl_dev; -memory_object_t iopl_mem; +mach_port_t device,mem_dev; +memory_object_t mem_mem; mem_mem is a rather weird variable name. Perhaps you could rename it to something clearer? Maybe mem_object... Well, from the point of view of Xorg, it is a device which gets mapped, even if inside gnumach it is called an object. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH,HURD] Fix use of deprecated iopl device
This fixes Xserver on GNU/Hurd into using the mem device instead of
the deprecated iopl device.
Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org
diff --git a/hw/xfree86/os-support/hurd/hurd_mmap.c
b/hw/xfree86/os-support/hurd/hurd_mmap.c
index ccef5f2..8b65ea0 100644
--- a/hw/xfree86/os-support/hurd/hurd_mmap.c
+++ b/hw/xfree86/os-support/hurd/hurd_mmap.c
@@ -39,8 +39,8 @@
int
xf86ReadBIOS(unsigned long Base,unsigned long Offset,unsigned char *Buf,int
Len)
{
-mach_port_t device,iopl_dev;
-memory_object_t iopl_mem;
+mach_port_t device,mem_dev;
+memory_object_t mem_mem;
vm_address_t addr = (vm_address_t)0; /* serach starting address */
kern_return_t err;
@@ -51,14 +51,14 @@ xf86ReadBIOS(unsigned long Base,unsigned long
Offset,unsigned char *Buf,int Len)
errno = err;
FatalError(xf86ReadBIOS() can't get_privileged_ports.
(%s)\n,strerror(errno));
}
-err = device_open(device,D_READ|D_WRITE,iopl,iopl_dev);
+err = device_open(device,D_READ|D_WRITE,mem,mem_dev);
mach_port_deallocate (mach_task_self (), device);
if( err )
{
errno = err;
FatalError(xf86ReadBIOS() can't device_open. (%s)\n,strerror(errno));
}
-err = device_map(iopl_dev,VM_PROT_READ|VM_PROT_WRITE, Base , BIOS_SIZE
,iopl_mem,0);
+err = device_map(mem_dev,VM_PROT_READ|VM_PROT_WRITE, Base , BIOS_SIZE
,mem_mem,0);
if( err )
{
errno = err;
@@ -69,13 +69,13 @@ xf86ReadBIOS(unsigned long Base,unsigned long
Offset,unsigned char *Buf,int Len)
BIOS_SIZE,
0,
TRUE,
-iopl_mem,
+mem_mem,
Base,
FALSE,
VM_PROT_READ|VM_PROT_WRITE,
VM_PROT_READ|VM_PROT_WRITE,
VM_INHERIT_SHARE);
-mach_port_deallocate(mach_task_self(),iopl_mem);
+mach_port_deallocate(mach_task_self(),mem_mem);
if( err )
{
errno = err;
diff --git a/hw/xfree86/os-support/hurd/hurd_video.c
b/hw/xfree86/os-support/hurd/hurd_video.c
index 4a99db3..6a34741 100644
--- a/hw/xfree86/os-support/hurd/hurd_video.c
+++ b/hw/xfree86/os-support/hurd/hurd_video.c
@@ -44,8 +44,8 @@
static pointer
mapVidMem(int ScreenNum, unsigned long Base, unsigned long Size, int Flags)
{
-mach_port_t device,iopl_dev;
-memory_object_t iopl_mem;
+mach_port_t device,mem_dev;
+memory_object_t mem_mem;
kern_return_t err;
vm_address_t addr=(vm_address_t)0;
@@ -55,7 +55,7 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned long
Size, int Flags)
errno = err;
FatalError(xf86MapVidMem() can't get_privileged_ports.
(%s)\n,strerror(errno));
}
-err = device_open(device,D_READ|D_WRITE,iopl,iopl_dev);
+err = device_open(device,D_READ|D_WRITE,mem,mem_dev);
mach_port_deallocate (mach_task_self(), device);
if( err )
{
@@ -63,7 +63,7 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned long
Size, int Flags)
FatalError(xf86MapVidMem() can't device_open. (%s)\n,strerror(errno));
}
-err = device_map(iopl_dev,VM_PROT_READ|VM_PROT_WRITE, Base , Size
,iopl_mem,0);
+err = device_map(mem_dev,VM_PROT_READ|VM_PROT_WRITE, Base , Size
,mem_mem,0);
if( err )
{
errno = err;
@@ -74,23 +74,23 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned long
Size, int Flags)
Size,
0, /* mask */
TRUE, /* anywhere */
-iopl_mem,
+mem_mem,
(vm_offset_t)Base,
FALSE, /* copy on write */
VM_PROT_READ|VM_PROT_WRITE,
VM_PROT_READ|VM_PROT_WRITE,
VM_INHERIT_SHARE);
-mach_port_deallocate(mach_task_self(),iopl_mem);
+mach_port_deallocate(mach_task_self(),mem_mem);
if( err )
{
errno = err;
- FatalError(xf86MapVidMem() can't vm_map.(iopl_mem)
(%s)\n,strerror(errno));
+ FatalError(xf86MapVidMem() can't vm_map.(mem_mem)
(%s)\n,strerror(errno));
}
-mach_port_deallocate(mach_task_self(),iopl_dev);
+mach_port_deallocate(mach_task_self(),mem_dev);
if( err )
{
errno = err;
- FatalError(xf86MapVidMem() can't mach_port_deallocate.(iopl_dev)
(%s)\n,strerror(errno));
+ FatalError(xf86MapVidMem() can't mach_port_deallocate.(mem_dev)
(%s)\n,strerror(errno));
}
return (pointer)addr;
}
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Do not trap access to timer and keyboard
Adam Jackson, le Fri 19 Mar 2010 14:29:55 -0400, a écrit : (Gedankenexperiment: Kernel and X attempt a config space cycle at the same time. Kernel writes to 0xCF8. X writes to 0xCF8. Kernel reads or writes to 0xCFC. Sure, I don't doubt such races can exist. What garbage does the kernel get now?) In the current state, all probing and initialization is only done once, and thus the Mach kernel doesn't do config stuff after having given hand to the bootstrap processes. Do you have a link to a bug that this is solving? http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00037.html A copy of the VBIOS would be useful here: # dd if=/dev/mem of=/tmp/vbios bs=64k skip=12 count=1 Cc-ing the request. Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Do not trap access to timer and keyboard
Adam Jackson, le Wed 17 Mar 2010 17:44:34 -0400, a écrit : On Sat, 2010-03-13 at 02:26 +0100, Samuel Thibault wrote: -ioperm(0x40,4,0); /* trap access to the timer chip */ -ioperm(0x60,4,0); /* trap access to the keyboard controller */ I'm not sold on this. You really do not want to be bashing these ports directly if the kernel also is. Sure. The issue is that some VESA BIOS do need it. If this _is_ right, then it almost certainly needs to be done for all platforms. Well, actually only Linux and Hurd used to do it. Since Linux also set iopl to 3 to be able to access to ports = 0x400, the I/O bitmask set by ioperm() is just completely ignored, and the same two lines in the Linux code don't have any effect. Do you have a link to a bug that this is solving? http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00037.html Samuel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Do not trap access to timer and keyboard
Some VESA BIOSes need to access to them. Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org --- hw/xfree86/os-support/hurd/hurd_video.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/os-support/hurd/hurd_video.c b/hw/xfree86/os-support/hurd/hurd_video.c index 4a99db3..e049ceb 100644 --- a/hw/xfree86/os-support/hurd/hurd_video.c +++ b/hw/xfree86/os-support/hurd/hurd_video.c @@ -124,8 +124,6 @@ xf86EnableIO() FatalError(xf86EnableIO: ioperm() failed (%s)\n, strerror(errno)); return FALSE; } -ioperm(0x40,4,0); /* trap access to the timer chip */ -ioperm(0x60,4,0); /* trap access to the keyboard controller */ return TRUE; } -- 1.7.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] libxcb: Fix authentication on hpux and Hurd
Fix authentication on hpux and Hurd
libxcb's 010e5661 (Fix XDM-AUTHORIZATION-1 (bug #14202)) mistakenly
inverted a few lines of code, making local socket authentication fail on
hpux and Hurd: when getpeername fails, sockname needs to be initialized
by getsockname before its address family can be checked.
Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org
diff --git a/src/xcb_auth.c b/src/xcb_auth.c
index 104f2f0..00aad23 100644
--- a/src/xcb_auth.c
+++ b/src/xcb_auth.c
@@ -260,10 +260,10 @@ int _xcb_get_auth_info(int fd, xcb_auth_info_t *info, int
display)
* case anyway.*/
if (getpeername(fd, sockname, socknamelen) == -1)
{
-if (sockname-sa_family != AF_UNIX)
-return 0; /* except for AF_UNIX, sockets should have peernames */
if (getsockname(fd, sockname, socknamelen) == -1)
return 0; /* can only authenticate sockets */
+if (sockname-sa_family != AF_UNIX)
+return 0; /* except for AF_UNIX, sockets should have peernames */
gotsockname = 1;
}
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libpciaccess x86 backend
Tiago Vignatti, le Tue 19 Jan 2010 18:44:06 +0200, a écrit :
I put some minor comments bellow. Make sure you send your future patches to
xorg-de...@lists.freedesktop.org instead.
Uh, I didn't even know that there were x.org lists.
On Sun, Jan 17, 2010 at 06:30:00PM +0100, ext Samuel Thibault wrote:
This adds support on x86 for OSes that do not have a PCI interface,
tinkering with I/O ports, and makes use of it on GNU/Hurd.
diff --git a/src/Makefile.am b/src/Makefile.am
index 4c06c25..8afd53b 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -51,6 +51,10 @@ else
VGA_ARBITER = common_vgaarb_stub.c
endif
+if GNU
+OS_SUPPORT = x86_pci.c
+endif
change the name for gnuhurd_pci.c makes more sense for me, given all file
there now are OS related.
Err, as I said, this is not specific to GNU/Hurd at all, it's just
an x86 backend that can be used for any OS that doesn't have a PCI
interface. Olaf, cc-ed, can probably comment on that.
+#if defined(__GNU__)
+
+#include sys/io.h
+
+static int
+x86_enable_io(void)
+{
...
+}
+
+static int
+x86_disable_io(void)
+{
...
+}
+
+#elif defined(__GLIBC__)
+
+#include sys/io.h
I'd put hearders on the top...
And duplicate the logic of #ifdef(__GNU__) / #ifdef(__GLIBC__)? That
sounds overdesign to me.
+#define PCI_HDRTYPE0x0E
+#define PCI_IRQ0x3C
No, you're being selfish :)
We should pick all PCI Vendors and Devices ID instead. Basically import all
hw/xfree86/common/xf86PciInfo.h and patch X server to remove it.
You mean move a header from the X server to libpciaccess? While I
agree it can make sense, it seems well beyond the goal of my patch, and
I don't really want to support all the breakage that will be brought
(xf86PciInfo.h is installed by the X server so anybody could already be
using it).
+static int
+pci_x86_conf1_probe(void)
again: I'd use the default pci_device_*, which is being used in the other
files..
Err, but it's not a function dealing with a device... I see that other
backends seem to use pci_system_ in that case.
Samuel
This adds support on x86 for OSes that do not have a PCI interface, tinkering
with I/O ports, and makes use of it on GNU/Hurd.
diff --git a/configure.ac b/configure.ac
index ffc1c8d..535d704 100644
--- a/configure.ac
+++ b/configure.ac
@@ -90,6 +90,9 @@ case $host_os in
solaris=yes
PCIACCESS_LIBS=$PCIACCESS_LIBS -ldevinfo
;;
+ gnu*)
+ gnu=yes
+ ;;
esac
AM_CONDITIONAL(LINUX, [test x$linux = xyes])
@@ -97,6 +100,7 @@ AM_CONDITIONAL(FREEBSD, [test x$freebsd = xyes])
AM_CONDITIONAL(NETBSD, [test x$netbsd = xyes])
AM_CONDITIONAL(OPENBSD, [test x$openbsd = xyes])
AM_CONDITIONAL(SOLARIS, [test x$solaris = xyes])
+AM_CONDITIONAL(GNU, [test x$gnu = xyes])
AC_SYS_LARGEFILE
diff --git a/src/Makefile.am b/src/Makefile.am
index 4c06c25..8afd53b 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -51,6 +51,10 @@ else
VGA_ARBITER = common_vgaarb_stub.c
endif
+if GNU
+OS_SUPPORT = x86_pci.c
+endif
+
libpciaccess_la_SOURCES = common_bridge.c \
common_iterator.c \
common_init.c \
diff --git a/src/common_init.c b/src/common_init.c
index 6b9b936..89c56ad 100644
--- a/src/common_init.c
+++ b/src/common_init.c
@@ -62,6 +62,8 @@ pci_system_init( void )
err = pci_system_openbsd_create();
#elif defined(__sun)
err = pci_system_solx_devfs_create();
+#elif defined(__GNU__)
+err = pci_system_x86_create();
#endif
return err;
diff --git a/src/pciaccess_private.h b/src/pciaccess_private.h
index 77eb57b..ef0 100644
--- a/src/pciaccess_private.h
+++ b/src/pciaccess_private.h
@@ -167,4 +167,5 @@ extern int pci_system_netbsd_create( void );
extern int pci_system_openbsd_create( void );
extern void pci_system_openbsd_init_dev_mem( int );
extern int pci_system_solx_devfs_create( void );
+extern int pci_system_x86_create( void );
extern void pci_io_cleanup( void );
diff --git a/src/x86_pci.c b/src/x86_pci.c
new file mode 100644
index 000..c42d3e0
--- /dev/null
+++ b/src/x86_pci.c
@@ -0,0 +1,669 @@
+/*
+ * Copyright (c) 2009 Samuel Thibault
+ * Heavily inspired from the freebsd, netbsd, and openbsd backends
+ * (C) Copyright Eric Anholt 2006
+ * (C) Copyright IBM Corporation 2006
+ * Copyright (c) 2008 Juan Romero Pardines
+ * Copyright (c) 2008 Mark Kettenis
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM
Re: libpciaccess x86 backend
Tiago Vignatti, le Tue 19 Jan 2010 21:10:37 +0200, a écrit :
But we have to go carefully with it and see if we will not be overlapping code
with libx86 - which currently is only doing real mode calls, but has already a
lot of IO related stuff:
http://cgit.freedesktop.org/~vignatti/libx86/tree/src/lrmi/common_io.c
libpciaccess could use inb_local instead of relying on glibc's macros,
yes, but I don't see any overlap apart from that.
+ * Read a VGA rom using the 0xc mapping.
+ */
+static int
+pci_device_x86_read_rom(struct pci_device *dev, void *buffer)
+{
+void *bios;
+int memfd;
+
+if ((dev-device_class 0x0000) !=
+((PCIC_DISPLAY 16) | ( PCIS_DISPLAY_VGA 8))) {
+ return ENOSYS;
+}
+
+memfd = open(/dev/mem, O_RDONLY);
+if (memfd == -1)
+ return errno;
+
+bios = mmap(NULL, dev-rom_size, PROT_READ, 0, memfd, 0xc);
+if (bios == MAP_FAILED) {
+ close(memfd);
+ return errno;
+}
+
+memcpy(buffer, bios, dev-rom_size);
+
+munmap(bios, dev-rom_size);
+close(memfd);
+
+return 0;
+}
for instance, with this one now, we'll have pretty much same implementations
inside X, libpciacccess and libx86.
Ok, but could this factorization be done as a separate effort? I find
it really out of scope of my patch :)
Samuel
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
