XSetInputFocus + XEmbed + Keyboard events to the wrong windows
Hello, there. I'm currently working on an implementation of XEmbed, and have run into a problem with XSetInputFocus. Please redirect me to the right forum if this was posted to the wrong place. What I'm troubled with is Keyboard Focus, described here: http://www.freedesktop.org/standards/xembed-spec/0.5-html/ar01s03.html In detail, the topmost embedder creates a not-visible X Window to hold the focus, the focus proxy. (It might be a 1x1 child window of toplevel located at -1,-1.) Since the focus proxy isn't an ancestor of the client window, the X focus can never move into the client window because of the mouse pointer location. In other words, whenever the outer window is activated (receives the X input focus), it has to put the X focus on the FocusProxy by calling XSetInputFocus(). focusProxy- * |A | |__ | | |B | | | |__| | || || So I have a window A with a focusproxy child window, measuring 1x1 at -1,-1, and I call XSetInputFocus on this focusproxy with RevertToParent. - To emphasize, B isn't a child window of A (in XEmbed, the embedder). B is a window created by a seperate application, which has called XReparentWindow to reparent B into A. So B is the XEmbed client. B actually fully covers A, so the size difference in my art is just for clarity. The problem is that the focusproxy receives all keyboard events only if the mouse pointer is outside window A (the embedder window). On or outside the window decorations, doesn't matter as long as the mouse pointer is outside window A. If the mouse pointer is inside window A, window B gets the keyboard events directly. If I move the mouse pointer out of the window A again, my focusproxy gets keyboard events again. Installing an x11 event filter gives me the EnterNotify and LeaveNotify for A and B as I cross the border of window A. I also get a KeymapNotify, and I guess (having no clue really) that this is X11's way of telling me that A isn't getting keyboard events anymore. So my question is this: Is the XEmbed protocol broken, is my X11 server broken, or is my code broken, and in which way. Any help will be greatly appreciated, Andreas :-) -- Andreas Aardal Hanssen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
smproxy and gnome-smproxy break the XSMP
Hello, Both smproxy and gnome-smproxy has a bug. I will describe this bug and propose solutions. First I recall one paragraph of the X session manager protocol (XSMP) specification: Some clients may wish to manage the programs they start. For example, a mail program could start a text editor for editing the text of a mail message. A client that does this is a session manager itself; it should supply the clients it starts with the appropriate connection information (i.e., the SESSION_MANAGER environment variable) that specifies a connection to itself instead of to the top level session manager. [end of section 3] So a simple client can be a session manager (sm for short) for a set of clients it starts itself. As the SESSION_MANAGER env variable is set to point on the simple client, the top level sm does not manage the clients which are XSMP compliant (because they connect to the simple sm). Now if one of these clients uses the old session manager protocol (based on the WM_COMMAND, WM_SAVE_YOUR_SELF, ...etc properties, see the appendix C of the ICCCM2) and if either smproxy or gnome-smproxy run, then the top level sm will manage this client. More exactly want can happen is a competition between the simple and the top level sm (via sm proxies, if the simple sm has a proxy) for managing the client. That's the bug. The reason is clear. When a top level window is mapped the sm proxies should compute the value of the SESSION_MANAGER ev on the application which maps the window and should ignore this window if this value is not equal to the proxy SESSION_MANAGER ev (or should connect the correct sm). Both smproxy and gnome-smproxy do not do that ... a good reason is that it is _not_ possible to do that (in general). I see two solutions: 1. Remove smproxy from XFree and gnome-smproxy from GNOME with the hope that all alive applications which use the old sm protocol will switch to the new one. Probably a bad solution ...? By the way it seems that KDE does not have and do not run by default a sm proxy. 2. Add a simple protocol between sm proxies and sm by using a property SESSION_MANAGER(STRING) which can be set by a sm (top level or not) on a leader window: A session manager can set on a leader window (which use the old session manager protocol) a property SESSION_MANAGER(STRING) set to the value of its network address (i.e., the value of its SESSION_MANAGER environment variable). A sm proxy should use this property to contact the correct sm or to ignore this window if it works for only one sm (e.g., the top level one) and the value of this property is not the network address of its session manager. The proxy should monitor the SESSION_MANAGER property and update the sm connection(s) accordingly (typically a window will map without the SESSION_MANAGER property set, if SM_CLIENT_ID is not set a concerned sm can then set the SESSION_MANAGER property). [We can do a more safe stuff: add a SESSION_MANGER_CHECK_WINDOW(Window) property that should be also set by the sm on the top level window and gives the id of a window which belongs to the sm and have the property SESSION_MANGER_CHECK(STRING) set to the value of the SESSION_MANAGER property. This can be used by a sm to answer the question: does an other alive sm already set the SESSION_MANAGER property?] It will be simple to modify smproxy and gnome-smproxy to avoid the bug by using this protocol (just monitor the SESSION_MANAGER property and if it is not equal to the value of the SESSION_MANAGER ev variable of the proxy, ignore the window). I can provide a patch for smproxy (which will be easy to apply to gnome-smproxy). In the future, if needed, one can imagine a sm proxy which works for all the running (master and simple) sm. I am not an XFree developer neither a GNOME developer. If the maintainers of smproxy and gnome-smproxy can be agree on a method to solve the described bug (as the solution proposed or any others), then the first step will be to modify smproxy and gnome-smproxy (I am ready to provide patches). The second step is to document the solution (Of course the sources code can be considered as a good documentation). I suggest that this should not be discussed now as this is useless if both smproxy and gnome-smproxy maintainers do not want to fix the described bug. Regards, Olivier ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 over Firewire !
Hi Dwipal, Le jeu 31/07/2003 00:07, Dwipal Desai a crit : that are very low. I want to use X directly over firewire so that stream of around 300 MB/s can be obtained. If I wanted to do this, I'd hack a firewire transport layer for X in xc/lib/Xtrans/ Mathieu -- Mathieu Lacage [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
rough code paths draft doc
hi,
I eventually got over my previous AddInputHandler puzzling and kept on
reading code until I finished the included rough outline of useful
code paths in the XServer.
I am planning to turn this into a real documentation but real life
matters make it unreasonable for me to finish this before the end of
august. As such, I thought some people might find it useful as-is.
Mathieu
--
Mathieu Lacage [EMAIL PROTECTED]
main:
-
xc/programs/Xserver/dix/main.c:main
hw/xfree86/common/xf86Init.c:InitOutput
hw/xfree86/common/xf86Init.c:InitInput
Xserver/dix/dispatch.c:Dispatch
hw/xfree86/common/xf86Events.c:ProcessInputEvents
Xserver/os/WaitFor.c:WaitForSomething
ReadRequestFromClient
result = (* client-requestVector[MAJOROP])(client) which ends in one of the
functions stored in dix/tables.c
dix/dispatch.c:ProcPolyPoint
include/dix.h:VALIDATE_DRAWABLE_AND_GC
ValidateGC
pGC-funcs-ValidateGC
XAAValidateGC
(*pGC-ops-PolyPoint)(pDraw, pGC, stuff-coordMode, npoint,(xPoint *)
stuff[1]);
InitOutput:
---
hw/xfree86/common/xf86config.c:xf86HandleConfig
hw/xfree86/common/xf86Config.c:configLayout
hw/xfree86/common/xf86Config.c:configInput
hw/xfree86/common/xf86Config.c:configInputKbd
set xf86Info.kbdEvents to one of xf86KbdEvents, xf86XqueEvents or
xf86WSKbdEvents.
driver-PreInit
driver/neomagic/neo_driver.c:NEOPreInit
driver/neomagic/neo_2070.c:Neo2070AccelInit
xaa/xaaInit.c:XAAInit
xaa/xaaInitAccel.c:XAAInitAccel (finish intialization of gc-ops)
Xserver/dix/dixutils.c:RegisterBlockAndWakeupHandlers (NoopDDA, xf86Wakeup)
InitInput:
--
foreach input driver specified in config file
driver-PreInit which ends in
hw/xfree86/input/mouse.c:MousePreInit
hw/xfree86/common/xf86helper.c:xf86AllocateInput
pInfo-read_input = MouseReadInput
pMse-PostEvent = MousePostEvent
foreach input driver registered with xf86AllocateInput
xf86Xinput.c:xf86ActivateDevice
dix/device.c:AddInputDevice
_AddInputDevice
dev-deviceProc = deviceProc;
xf86XinputFinalizeInit
one of RegisterPointerDevice or RegisterKeyboardDevice
device-public.processInputProc = ProcessKeyboardEvent;
device-public.realInputProc = ProcessKeyboardEvent;
device-ActivateGrab = ActivateKeyboardGrab;
device-DeactivateGrab = DeactivateKeyboardGrab;
if (no XInput support)
:mieqInit (register core keyboard and pointer)
else
hw/xfree86/common/xf86XInput.c:xf86eqInit (register core keyboard and pointer)
xf86EventQueue.pKbd = pKbd;
xf86EventQueue.pPtr = pPtr;
ProcessInputEvents:
---
if (no XInput support)
Xserver/mi/mieq.c:mieqProcessInputEvents
else
Xserver/hw/xfree86/common/xf86Xinput.c:xf86eqProcessInputEvents
if (key pressed)
(*xf86EventQueue.pKbd-processInputProc)
Xserver/dix/events.c:ProcessKeyboardEvent
DeliverGrabbedEvent or DeliverDeviceEvent
else if (mouse event)
(*(inputInfo.pointer-public.processInputProc))
Xserver/dix/events.c:ProcessPointerEvent
DeliverGrabbedEvent or DeliverDeviceEvent
DeliverEventsToWindow
TryClientEvents
WriteEventsToClient
Xserver/os/io.c:WriteToClient
ReplyCallback -- used by other pieces of code interested
in the reply going out
if (not enough data)
bufferize
else
FlushClient
xc/lib/xtrans/Xtrans.h:_XSERVTransWritev
xc/lib/xtrans/Xtrans.c:ciptr-transptr-Writev which
ends in
xc/lib/xtrans/Xtranslcl.c:TRANS(LocalWritev)
(local case)
xc/lib/xtrans/Xtranssock.c:TRANS(SocketWritev)
(networked case)
WaitForSomething:
-
while (1) {
Xserver/dix/dixutils.c:ProcessWorkQueue
Xserver/dix/dixutils.c:BlockHandler (invoke each function in the BlockHandler
list with the waittime as param)
hw/xfree86/common/xf86Events.c:xf86Wakeup
if (events) {
xf86Info.kbdEvents which ends in
hw/xfree86/common/xf86Events.c:xf86PostKbdEvent (convert hardware
keycode into X keycode)
ENQUEUE
EqEnqueue
__EqEnqueue
xc/programs/Xserver/hw/xfree86/common/xf86Xinput.c:xf86eqEnqueue
(insert event in
xf86EventQueue.events)
foreach fd which is an input dev, pInfo-read_input which ends in
Re: XSetInputFocus + XEmbed + Keyboard events to the wrong windows
On Thu, 2003-07-31 at 09:29, Andreas Aardal Hanssen wrote: Hello, there. I'm currently working on an implementation of XEmbed, and have run into a problem with XSetInputFocus. Please redirect me to the right forum if this was posted to the wrong place. What I'm troubled with is Keyboard Focus, described here: http://www.freedesktop.org/standards/xembed-spec/0.5-html/ar01s03.html Note that [EMAIL PROTECTED] would likely be a better place for this mail, since that's the normal place for discussing the freedesktop.org specifications. [...] XSetInputFocus(). focusProxy- * |A | |__ | | |B | | | |__| | || || So I have a window A with a focusproxy child window, measuring 1x1 at -1,-1, and I call XSetInputFocus on this focusproxy with RevertToParent. - To emphasize, B isn't a child window of A (in XEmbed, the embedder). B is a window created by a seperate application, which has called XReparentWindow to reparent B into A. So B is the XEmbed client. B actually fully covers A, so the size difference in my art is just for clarity. I assume you mean B wasn't created as a child window of A. If it has been successfully reparented into A, it will then be a child window of A. The problem is that the focusproxy receives all keyboard events only if the mouse pointer is outside window A (the embedder window). On or outside the window decorations, doesn't matter as long as the mouse pointer is outside window A. If the mouse pointer is inside window A, window B gets the keyboard events directly. If I move the mouse pointer out of the window A again, my focusproxy gets keyboard events again. Are you sure that the focusproxy window is getting the events, not window A? It sounds very much to me like you simply didn't manage to get the focus set to the focusproxy window. Note that the focus has to be set to the focusproxy window each time that the toplevel gets focused; this requires participating in the WM_TAKE_FOCUS protocol as described in the ICCCM. Installing an x11 event filter gives me the EnterNotify and LeaveNotify for A and B as I cross the border of window A. I also get a KeymapNotify, and I guess (having no clue really) that this is X11's way of telling me that A isn't getting keyboard events anymore. No, keymap notifies shouldn't be related. So my question is this: Is the XEmbed protocol broken, is my X11 server broken, or is my code broken, and in which way. Definitely your code is broken; the setup in XEMBED works fine for GTK+, for KDE, on a wide ranger of different X servers. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Thu, Jul 31, 2003 at 07:15:43AM +0200, Alexander Pohoyda wrote: David Dawes [EMAIL PROTECTED] writes: going back to 3.3. Unless someone comes up with a better solution, that's what I'm planning to do. OK, it seems to be the best solution in this situation. I dare to propose another solution, however: to delete the `geometry' directory and created a new one (named `geometry2` or `geom` or whatever) which will have companies as lowercased directories. Is there a reason why the extra geometry descriptions couldn't be added to the original 'hp' file instead of putting them in separate files in a subdirectory? XKB should allow multiple descriptions per file. Yes, that's right. This is not a limitaton of XKB. If you have a look into newly created geometry, you'll see that it already contains 3 sections, which are nested and re-used: 1. for the mouse stick 2. for the base frame and common buttons 3. for US keyboard layout. Some other geometries (like ibm/thinkpad) have also 4. for national layouts. I believe that this is a correct way to develop geometries for related keyboards and I think that it is logical to combine them into one file. Knowing all the problems now, I would still prefer this solution. I have already developed 4 geometry specifications and will continue to do so. I don't want to create problems, though :-) OK, so if I understand you correctly, we can re-add the old 'hp' file, and add the omnibook descriptions to it. New descriptions for other vendor keyboards can be added to existing files rather than creating new directories. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: smproxy and gnome-smproxy break the XSMP
On Thu, Jul 31, 2003 at 03:25:23PM +0200, Olivier Chapuis wrote: 1. Remove smproxy from XFree and gnome-smproxy from GNOME with the hope that all alive applications which use the old sm protocol will switch to the new one. Probably a bad solution ...? By the way it seems that KDE does not have and do not run by default a sm proxy. I agree with Owen that this is right, the smproxy stuff is just a bad idea. I think KDE does have some try to manage non-SM apps code also, I don't remember the details though. Someone was claiming that KDE successfully restarts netscape/mozilla for example. My memory is that I tried to find the code that did this and didn't succeed. Anyway, so I don't know whether it would have the same issue or not. Havoc ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Knowing all the problems now, I would still prefer this solution. I have already developed 4 geometry specifications and will continue to do so. I don't want to create problems, though :-) OK, so if I understand you correctly, we can re-add the old 'hp' file, and add the omnibook descriptions to it. That's right, we can. New descriptions for other vendor keyboards can be added to existing files rather than creating new directories. OK, let's do it this way. Some brands just had luck to be created as directories in the first place. -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XSetInputFocus + XEmbed + Keyboard events to the wrong windows
On Thu, 31 Jul 2003, Owen Taylor wrote: On Thu, 2003-07-31 at 09:29, Andreas Aardal Hanssen wrote: - To emphasize, B isn't a child window of A (in XEmbed, the embedder). B is a window created by a seperate application, which has called XReparentWindow to reparent B into A. So B is the XEmbed client. B actually fully covers A, so the size difference in my art is just for clarity. I assume you mean B wasn't created as a child window of A. If it has been successfully reparented into A, it will then be a child window of A. Yes, that was what I meant. It's certainly a child window but it wasn't created as one. events directly. If I move the mouse pointer out of the window A again, my focusproxy gets keyboard events again. Are you sure that the focusproxy window is getting the events, not window A? It sounds very much to me like you simply didn't manage to get the focus set to the focusproxy window. You're right, it's window A that gets the events and not the focus proxy. :-) Note that the focus has to be set to the focusproxy window each time that the toplevel gets focused; this requires participating in the WM_TAKE_FOCUS protocol as described in the ICCCM. I'll dig more into this here. So my question is this: Is the XEmbed protocol broken, is my X11 server broken, or is my code broken, and in which way. Definitely your code is broken; the setup in XEMBED works fine for GTK+, for KDE, on a wide ranger of different X servers. Thanks :-) Andy -- Andreas Aardal Hanssen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
David Dawes [EMAIL PROTECTED] writes: On Thu, Jul 31, 2003 at 07:15:43AM +0200, Alexander Pohoyda wrote: I believe that this is a correct way to develop geometries for related keyboards and I think that it is logical to combine them into one file. OK, so if I understand you correctly, we can re-add the old 'hp' file, and add the omnibook descriptions to it. New descriptions for other vendor keyboards can be added to existing files rather than creating new directories. If you decide to go this way, please let me know and I will be happy to prepare new diffs. This strategy will require some re-arrangements: instead of accessing a `hp/omnibook(us)', we'll need to do `hp(omnibook.us)' or whatever. Actually, we are trying to fit company/family/model/variant into 2-level structure file/section. -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Rewrite of the NV driver
In CVS I have just checked in something I've been working on for a few weeks. It is a substantial rewrite of the nv driver, the main changes being removal of Riva128 into a separate module and a complete rewrite of the graphics acceleration for TNT and GeForce chips. Aspects of the driver operation that do not have anything to do with acceleration have not changed. Summary: 1) Riva128 support is moved out of the nv driver and into a separate riva128 module, which is essentially the old nv driver stripped down to support only the Riva128. Riva128 support has not changed from the previous driver and you still specify driver nv for it. The new nv driver will load the riva128 module for the legacy support when it needs to. So it is essentially two drivers: one for Riva128 and a rewritten one for newer chips, but you get either by specifying the nv driver. 2) I've moved from using MMIO to program the graphics engine over to video ram command buffers. This makes programming of the engine more efficient. 3) The driver supports a hardware planemask now. 4) I've added support for scaled blits and they are being exposed as a new Xv adaptor which exports YUV formats and an 8:8:8:8 XRGB format. 5) GeForce products now support virtual desktops up to 4080x4096 (was 2048x2048). 6) Updated many timing parameters for GeForce3, GeForce4 Ti and GeForceFX chips, so those should have better performance now. Testers appreciated. It works on all the cards I've tested on, but you know how these things go... Something is bound to have broken somewhere. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
