Re: Question about Double Buffering
Dyweni - Xorg wrote: I am trying to setup my xorg server (1.10.3) to use double buffering. I have the Nvidia 9600 video card and am using the proprietary nvidia driver. When I run glxinfo, I see 'None' and 'Ncons' in the right most column. I do not see any entry with a 'P' (to indicate support for OpenGL pixel buffers). I have the 'DBE' module being loaded (xorg.0.log confirms that it loads). OpenGL pixel buffers (pbuffers), OpenGL double-buffering, and the DBE extension are all unrelated to each other. Support for pixel buffers is indicated by the presence of GLX_SGIX_pbuffer in the extension list. Whether a GLX visual is double-buffered is indicated by the db column in the glxinfo output. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: How to set default window size for xconsole app ?
Aaron Lewis wrote: Hi , i wanted to setup default window size for xconsole program , although i'm on openbox , but still wanted to use Xdefaults file , but how ? XConsole.width: 640 XConsole.height: 480 -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Ideas for X improvement.
Alan Coopersmith wrote: http://en.wikipedia.org/wiki/Xpra http://code.google.com/p/partiwm/wiki/xpra This is the VNC approach (render locally, forward raster data), but done on a window-by-window basis using compositing. As such, it suffers from most of the same problems as x11vnc (acceleration requires local video hardware, limited by frambuffer read speed, inter-client communication needs explicit handling, etc). AFAICT, the only advantage is rootless operation. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Ideas for X improvement.
David Jackson wrote: The main thing to bear in mind is the client-server model. If you want to migrate a connection to a different X server, you either have to ensure that the new X server will behave exactly like the old one, or make the client adjust to the change. The former is somewhere between ridiculously difficult and completely impossible, while the latter requires significantly changing the protocol, libraries, toolkits, and applications. The client wouldnt have to be moved between servers at all, it could be the same proxy server, the proxy server could then open up connections to actual X servers and forward things to the real X servers. The proxy would massage and rework data as necessary to trick the X client and hide the fact it is being displayed to many X servers and also keep the X servers in the dark about what is really going on as well. This is the first option, ensure that the new X server will behave exactly like the old one. This requires no protocol changes and no changes to the clients or servers. There are already two or more codebases that this has already been done on, one is something called Xmux, the other was something called Xshare or something, and I am aware of a possible third that was called XTV. None are actively developed at this time. XMX, Xmux, XTV and SharedX are discussed in A Survey of X Protocol Multiplexors. The only reference I can find to Xshare is a brief description from its author on a page which hasn't been updated since 2001. I'm sure there have been more recent attempts, but none of those seem to have been any more successful. The main reason why these projects never go anywhere is that it's difficult if not impossible to make them work once you stray beyond the core features of the core X11 protocol, and the simplest applications. If you're only dealing with the core protocol, it's not too hard to reasonably approximate the capabilities of one server on all of the others. Having said that, all of the programs described in the above paper had some problems even with the core protocol. But this falls down when you try to handle something like OpenGL, where the client queries the capabilities of the server and adjusts its behaviour accordingly. It's simple enough for a client to use a feature if it's available and avoid it if it isn't. It's a different matter for a proxy/mux/etc to try to forward a connection from a client which is using a feature to a server which doesn't have it (or which has a more limited implementation). It also starts to fall down when you move beyond a single, isolated application to something which integrates with a complex desktop environment. E.g. if client A communicates with client B, do you proxy client B as well, and have each instance of client A communicate with the matching instance of client B, or just have the primary instance of client A communicate with a single instance of client B? Of the four programs in the paper, only Xmux got a strong pass for supporting cut and paste. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Ideas for X improvement.
David Jackson wrote: I am know C, however I know little about X internals or X protocol. Is there a good source of documentation that would give a person a full introduction and overview of how the X server works,including how it all fits together, and a tour of the system and documentation of the internals such as functions, variables etc? Basically everything need for a person who only knows C to learn all about how the X server works? How a specific implementation works doesn't really matter, as that's something which can be changed. What can't be changed (without breaking compatibility) is the protocol. The relevant documentation can be found here: http://www.x.org/releases/X11R7.6/doc/ The main thing to bear in mind is the client-server model. If you want to migrate a connection to a different X server, you either have to ensure that the new X server will behave exactly like the old one, or make the client adjust to the change. The former is somewhere between ridiculously difficult and completely impossible, while the latter requires significantly changing the protocol, libraries, toolkits, and applications. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Ideas for X improvement.
for physical display. 2. Use GUI toolkits which offer an abstract, high-level interface to the client. The toolkit has the ability reconstruct and clone windows at will. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: ssh -Y -l user etc,etc
gene heskett wrote: Note that if you change DISPLAY manually (via export), you may also need to update the X authentication credentials with xauth. I recall I did have to use xauth at one time, years ago. Unforch, no man pages for it are installed, and the --help output is criminally concise. If I do an 'xauth list', it only spits out one cookie, for the wap11 at *.*.*.100 on my local network. Is that on shop or coyote? ssh -Y shop ... (or -X) should add an xauth entry on shop along the lines of: shop/unix:10 MIT-MAGIC-COOKIE-1 fedcba9876543210fedcba9876543210 It should do this regardless of whether coyote's X server uses xauth-style authentication (which is typically the case when started via a display manager such as xdm, gdm, kdm, etc) or xhost-style authentication (which is typically the case when started directly or via startx). However: it *doesn't* do this if you have a ~/.ssh/rc or /etc/ssh/sshrc script. In that case, sshd passes the authentication data to the script's stdin, and the script has to create the xauth entries itself. This step is non-optional if you want to use X11 forwarding; if you have an rc script and it doesn't add the xauth data, sshd's X proxy will end up refusing the connections. The SSHRC section in the sshd(8) manpage goes into more detail. X11UseLocalHost is #X11UseLocalhost yes in /etc/ssh/sshd_config commented out. Does changing that need a reboot? It requires restarting sshd, either with kill -HUP ... or whatever mechanism your Linux distribution uses for managing services (e.g. something like: /etc/init.d/sshd restart). But I don't think that will make any difference. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: ssh -Y -l user etc,etc
gene heskett wrote: So that probably explains where the 10.0 is coming from, but not where I might change it? That seems to be the $64k question... Why do you need to change it? The actual display number is determined by the X11DisplayOffset setting in the sshd_config file. sshd allocates display numbers for X proxies starting at that value. The default is 10, which is enough to ensure that the numbers won't conflict with real X displays on any normal system. Note that if you change DISPLAY manually (via export), you may also need to update the X authentication credentials with xauth. By default sshd will only accept connections on the loopback address (127.0.0.1). If you try to connect to coyote:10, the connection will probably use another address (i.e. the address assigned to the physical network adapter) and be refused. You can change this behaviour via X11UseLocalhost in sshd_config, but in the absence of some form of firewall, that will allow other hosts on the network to connect to the X proxy. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XOpenDisplay
Al'miev Il'dar wrote: Hello, i am a beginner in X-Windows, i have a question: in the function XOpenDisplay(display_name), where display_name=hostname:displaynumber.screennumber, 1) does hostname mean a name of a computer, physically existing, where it would be necessary to open a graphical applications (that is a computer-client), or is it a computer-server ? It's the name of the computer running the X server which the application wishes to use. 2) what is displaynumber and screennumber in terms of physically existing displays-screens and computer-client(s) and computer-server ? A display is an X server. You can run multiple X servers on a single computer. In the most common case, the computer arbitrates access to the keyboard, mouse and display, but it can also work if you have multiple keyboards/mice/displays, or if the X server is using virtual hardware, e.g. Xvnc. 3) what is the difference between the terms display and screen ? Each display is a separate X server, with a keyboard, mouse and one or more monitors. A screen corresponds to a single monitor on systems which don't split a single logical screen across all monitors. 4) if display_name=NULL, then display is opened in the local computer If you pass NULL as the display name, the value of the DISPLAY environment variable is used. This may or may not refer to the local system. - this is implicit designation of the local computer, How to provide display_name explicitly ? that is would it work for example: local:0.0 ? Omit the hostname for a local display, e.g. :0 for the first X server running on the local host. If no hostname is given, the connection will be to a Unix-domain socket in /tmp/.X11-unix. If a hostname is used, the connection will be a TCP connection to port 6000 plus the display number on the specified host. A connection via a Unix-domain socket is more likely to succeed than one via TCP; X servers are often configured to ignore TCP connections as a security measure. It's also more efficient. 3) is it possible to provide hostname=1.2.3.4. (which is an IP-address), instead of the name of the computer ? Yes. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Possibly silly, certainly a little OT Question
gene heskett wrote: Are the authors of minicom still available? Or how about src code? I found some names in the docs and sent an email to those, but it bounced and that was probably 2 years back up the log. The source code is available from: http://alioth.debian.org/projects/minicom -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Possibly silly, certainly a little OT Question
gene heskett wrote: I have a minicom session connected to a serial port of an antique computer, and the diffs in the keyboard codes for the control characters are killing me because I can't use the uparrow repeat functions of the terminal software driver on that machine. The arrow keys in particular, as sent from this end are just garbage chars to the old machine. So the first thing I need to map is from whatever the up arrow key now sends, to actually send an 0x09 to the other end of the cable. But I haven't a clue how to go about that. I've looked through minicom's menu's, and it looks like I can translate the printable characters, but I don't see where I can diddle the control chars. I've also look at the setserial options without anything useful reaching up and slapping me in the face. Can anyone suggest a better configuration tool/location of a file, whatever, that would give me the data as to how to do this for minicom only? Minicom doesn't support remapping of the cursor keys; you get to choose between VT100 and ANSI, and that's all. One possibility is to run it under screen, which allows arbitrary remapping of keys, and remap the cursor keys to function keys (which can then be rebound within minicom). Another possibility is to modify minicom's source code. Yet another possibility is to just type literal control characters, but that's likely to be annoying if you need to do it a lot. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Any plan to promote coordinats to 32 bits?
Teika Kazura wrote: X coordinates are 16 bits, but are there any plan to promote them to 32 bits? I couldn't find one in the Xorg site. In fact, 16 bits are not sufficient these days. If you have several screens and enlarge your desktop with a window manager to several X screens width / height, it can easily exceed 32767. No, it can't exceed 32767; you might /want/ to exceed that, but that's a different matter. Is this fact known to X developement society? Yes. E.g. if you want to create a viewport on a much larger canvas, you can't just create a child window the size of the canvas and scroll by changing its (parent-relative) position. You have to implement transformation and clipping yourself. The limitations on the core X protocol aren't likely to change; it would cause too much breakage. For graphics, you can just use Render, cairo, OpenGL, etc. I don't think that the 16-bit limitation on the size of a window is likely to be a problem for the foreseeable future (apart from anything else, you're likely to run into memory issues with backing store or compositing buffers before that). If you want large virtual desktops, the WM just needs to be creative. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: mixed OpenGL vendor drivers
Kai-Uwe Behrmann wrote: ATI and Nvidia ship separate version of libGL.so, for Linux and probably for other operating systems. Now I want to make a Live media with out of the box fantastic OpenGL support for a wide range of graphic cards. Is the replacement by vendors of libGL something dictated by the architecture of Xorg or the OpenGL spec? No. What are good solutions to switch the library on the fly? Put each version in a separate directory. Create a symlink from /usr/lib/libGL.so to the default version. Set LD_LIBRARY_PATH if you need to use a different version on a per-process basis (e.g. if DISPLAY points to a remote display and the default libGL can't handle that). -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Non-resizable window
Burton Samograd wrote: I was wondering if there was a standard way to create a window using Xlib and have it be non-resizable (like a dialog). Would this be through a window manager hint or something like window creation flags? See XSetWMSizeHints. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xopendisplay no display varibale declared
yoni dana wrote: I have a software which is loaded before the X server is running. After the X server is up,I try to use the xopendisplay function with NULL , parameters and fails.(Reason no display parameter declared) Any idea how to solve this problem? Either set $DISPLAY, or pass something other than NULL as the display argument to XOpenDisplay(). Ideally, the program should provide a -display switch to specify the display to connect to. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xopendisplay no display varibale declared
yoni dana wrote: Thanks for display. I pass as a parameter :0.0 and it works. But if i have a problem if two screen are connected to the computer or remote desktop connection, What problem? The reason i need to use XOpenDisplay is to retrieve screen resolution. Is there another way to do it Any X application needs to know which X server to connect to. The resolution is a property of a screen, not a display (which can have multiple screens). Once you have a connection to a display, you can determine the number of screens with the ScreenCount() macro, and you can get a reference to an individual screen with the ScreenOfDisplay() macro. Or you can get the default screen via DefaultScreenOfDisplay(), and run the program with a display of e.g. :0.1 (the number after the dot specifies the default screen). With remote-desktop protocols such as VNC, it may be impossible to determine the resolution of the physical screen. This may not even be a meaningful question, as there won't be a physical screen when no viewer is connected, and there will be multiple physical screens when multiple viewers are connected. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Reasons for FreePicture to cause RenderBadPicture?
Clemens Eisserer wrote: Pixmaps are reference-counted and the picture takes a reference on the pixmap, so the pixmap can't go away before the picture. However this isn't true for windows, so as soon as the window is destroyed presumably the picture is destroyed as well or becomes invalid. Can this be considered as bug? I just tried the same for GCs and XFreeGC doesn't generate any error when the Window has already been destroyed. Sure there is an implementation detail behind it, but GCs don't show the same behavour and the whole thing somehow feels quite inconsistent :( GCs aren't associated with a window. The drawable passed to XCreateGC is used to specify the screen and depth, but has no significance beyond that. A GC may be used with any drawable having the correct screen and depth. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
Donnie Berkholz wrote: Which brings me to something I always wondered about: Why is there no X pendant for screen (or I'm not aware of it)? I.e. some proxy X server, opening an additional display passing through X transparently, keeping record of prerequisite resources. Because it's ridiculously difficult. Something like Xpra code.google.com/p/partiwm/wiki/xpra? That's essentially Xvnc except that it uses Composite to do it window-by-window rather than for the whole screen. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
Wolfgang Draxinger wrote: Which brings me to something I always wondered about: Why is there no X pendant for screen (or I'm not aware of it)? I.e. some proxy X server, opening an additional display passing through X transparently, keeping record of prerequisite resources. Because it's ridiculously difficult. And make this proxy de-/attachable. So far I emulated such using Xvnc, but that means no HW acceleration, no indirect GLX and such things. Of course such a thing boils down to implementing an almost fully featured X server, so if I were to implement such a thing, I'd probably start of kdrive/Xephyr. It's actually harder than a fully-featured X server. A normal X server knows what hardware it's dealing with, and the hardware doesn't change while it's running. A proxy has to deal with the case where it disconnects from one server and connects to one with completely different parameters. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Getting crazy over transparency
Rashid wrote: I dont know why, but im to stupid to blitting transparent images with xlib. DAMN, with SDL was ist quite easy. Dont know if someone want to help me, but im trying it since days and getting mad over time... Can someone have a quick look, why it isnt working? skullmask.xpm is a 1 bit image. Use ./built für building (make is for cross compiling). The whole stuff is in the zip archive. I would be realy happy someone would help me. Error Message: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 56 (X_ChangeGC) Serial number of failed request: 50 Current serial number in output stream: 1404 if (XpmReadFileToPixmap (mainwindow-display, mainwindow-window, skullmask.xpm, skullImage.clipmask, maskshade, NULL)) You have the parameters backwards; the pixmap comes before the mask. Consequently, skullImage.clipmask contains the pixmap, while maskshade contains the mask. That causes this: XSetClipMask(mainwindow-display, mainwindow-gc, skullImage.clipmask); to fail, as the clip mask isn't a bitmap (1-bit per pixel). -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Transparent Color in blitting with X11
Peter Harris wrote: but xlib doesnt support an alpha channel (and the freerunner has only 16 bits per pixel). is there an easy way to do transparency (one transparent color is enough) with xlib or a toolkit which builds on it? If you can easily extract that color into a 1-bit bitmap, you can use XSetClipMask. Alternatively, you can do it in two steps: XSetFunction(dpy, gc, GXandInverted); XSetBackground(dpy, gc, 0UL); XSetForeground(dpy, gc, ~0UL); XCopyPlane(dpy, mask, win, gc, ..., 1UL); XSetFunction(dpy, gc, GXor); XCopyArea(dpy, image, win, gc, ...); The image must have all background (transparent) pixels set to zero. Also, you can use XPutImage() instead of XCopyPlane() and XCopyArea(). -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: How Can I create a second display? (virtual maybe???)
Jimmy Spam wrote: I have a .sh script which have this line: export DISPLAY=localhost:13 and only work fine if vnc is running it's very strange. I suppose that vnc create a new display (13) and if it isn't running, this display doesn't exist and script fail. Can I create a second display directly with Xorg, set the DISPLAY variable of the script to this second display and stop vnc I want launch this script without need of run vnc. Unless the user need to interact with clients started from the script, running Xvnc is likely to be preferable to running a real X server. If there's a reason to avoid Xvnc, try Xvfb instead. Running a real X server requires that the system has video hardware, that you have the necessary permissions to use it, and (if you want to run more concurrent X servers than you have video cards), that the hardware (and its driver) is capable of sharing the card between multiple X servers. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: CLIPBOARD selection doesn't save content
Quintus wrote: Apart from implementing the CLIPBOARD selection, the application should implement the SAVE_TARGETS protocol for optimum behaviour with modern clipboard managers. For details, see: OK, I've done so (hopefully). http://www.freedesktop.org/wiki/ClipboardManager After rereading this document, I think I finally got how the mechanism works. Can you confirm this: 0. The clipboard manager acquires the CLIPBOARD_MANAGER and CLIPBOARD selections. 1. My application acquires CLIPBOARD, acting just as if it were PRIMARY. 2. My application wants to exit. Therefore, it 1. Sets a property, say, MY_SELECTION, to the targets it wants the clipboard manager to preserve the content. 2. Requests the X server to convert the CLIPBOARD_MANAGER selection to SAVE_TARGETS, by passing my application window and the MY_SELECTION property. 3. The clipboard manager gets notified (by a SelectionRequest event) and now queries my application for each target I set MY_SELECTION to. 4. The clipboard manager sends my application a SelectionNotify event with property SAVE_TARGETS (or None if it has failed to save the content) indicating that is has completed 5a. The clipboard manager takes ownership of the CLIPBOARD selection 5b. (parallel to 5a) My application exits I believe this is correct, but I haven't actually written low-level selection-handling code since the SAVE_TARGETS protocol was created. In the end, my application hopefully is just my function, otherwise I would have to go to subprocesses. Yes. From the X server's perspective, a function which opens a connection, runs an event loop then closes the connection is indistinguishable from a more typical client. Successive calls to that function would appear as distinct short-lived clients. The server only sees connections; what happens on the client side of those connections is irrelevant. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: CLIPBOARD selection doesn't save content
Quintus wrote: Now, I'm trying to implement writing, only for the CLIPBOARD selection, since that one's contents should persist across program death.I know, I have to acquire CLIPBOARD's ownership; afterwards the xclipboard process would send me a TARGETS request asking me what data I provide. I answer this with TARGETS, UTF8_STRING, XA_STRING and TIMESTAMP, which should cause xclipboard to ask me for UTF8_STRING or XA_STRING, but... It doesn't. Instead, if I try to paste the copied text into an application, my program gets a request from that application rather than from xclipboard. Further more, when my program finishes, the data is gone. So I suppose, something is wrong at my side. X itself doesn't have a persistent clipboard. If you want the clipboard contents to persist after the application terminates, a clipboard manager must be running. Clipboard managers are something of a mixed blessing, so not everyone uses one. Whether a clipboard manager is in use and its exact behaviour are dependent upon the desktop environment. All that your program can do is to implement the relevant protocols; the rest is beyond its control. Apart from implementing the CLIPBOARD selection, the application should implement the SAVE_TARGETS protocol for optimum behaviour with modern clipboard managers. For details, see: http://www.freedesktop.org/wiki/ClipboardManager If a compliant clipboard manager is running, this should cause it to take over the clipboard (ownership and contents) from the terminating process. Older clipboard managers (and clients) don't support the SAVE_TARGETS protocol, which means that the clipboard manager must retrieve the clipboard contents whenever the clipboard changes, which can be inefficient if the data is large and/or if there are many targets (some of which may be computationally expensive to generate). -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with pure X11 program's Fonts
Aaron Lewis wrote: open xfontsel , and choose a good font , then use select to copy , use xrdb to reload configuration. Still got an ugly fonts .. This time , i tried with putty , i checked and thought it's pure X11 program. (checked the library it linked) My ~/.Xdefaults is in attachment . Now , i was wondering if i made some mistakes .. ldd of CrossOver Main UI: linux-gate.so.1 = (0xe000) libm.so.6 = /lib/tls/i686/cmov/libm.so.6 (0x008cb000) libdl.so.2 = /lib/tls/i686/cmov/libdl.so.2 (0x0099e000) libSM.so.6 = /usr/lib/libSM.so.6 (0x004e1000) libICE.so.6 = /usr/lib/libICE.so.6 (0x00e63000) libXext.so.6 = /usr/lib/libXext.so.6 (0x0070c000) libX11.so.6 = /usr/lib/libX11.so.6 (0x0030a000) libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0x00c78000) /lib/ld-linux.so.2 (0x0043d000) libXau.so.6 = /usr/lib/libXau.so.6 (0x0011) libxcb-xlib.so.0 = /usr/lib/libxcb-xlib.so.0 (0x00113000) libxcb.so.1 = /usr/lib/libxcb.so.1 (0x00116000) libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0x00e5d000) Xt-based toolkits use X resources for configuration, but CrossOver doesn't appear to be using such a toolkit. Other toolkits *might* use X resources, or they might not. Assuming that CrossOver is the Windows emulation software based upon Wine and formerly known as CrossOver Office, I wouldn't expect it to support configuration via X resources. I suggest that you refer to the CrossOver documentation for guidance. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with pure X11 program's Fonts
Aaron Lewis wrote: Assuming that CrossOver is the Windows emulation software based upon Wine and formerly known as CrossOver Office, I wouldn't expect it to support configuration via X resources. I suggest that you refer to the CrossOver documentation for guidance. Thanks , Glynn . strace told me it reads ~/.Xdefaults-HOSTNAME In which case, it may be reading *some* configuration information via X resources, or it may just be a particular library which does so (it's linked against libdl, so I don't know which other libraries it may be loading dynamically). Conventionally, X resources are read from the file specified by $XENVIRONMENT, or ~/.Xdefaults-hostname if that variable is not set, and also read from the RESOURCE_MANAGER property on the root window, or from ~/.Xdefaults if the property doesn't exist. xrdb sets the RESOURCE_MANAGER property, so if you've used xrdb, the ~/.Xdefaults file won't be read. You can use xprop -root will list any properties on the root window. Conventionally, fonts are specified by font, fontSet and/or fontList resources. Athena uses fontSet if the international resource is True and font otherwise, while Motif uses fontList. Xt-based programs which have had Xft support added (e.g. xterm) tend to use faceName and faceSize. Having said all that, there's no guarantee that CrossOver's font configuration is influenced by X resources in any way. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Send String to Window input field
a...@ac13.de wrote: I try to send a string to an input field of an application. I think the only way is to use the XSendEvent function and send the keycode of every single character of my string. But how could I get the special keys like shift or alt for characters like '%'? XKeysymToKeycode() converts KeySyms to keycodes. You can find the keysyms in X11/keysymdef.h, e.g. XK_percent for '%'. Or you can look at the output from xmodmap -pk, and add the XK_ prefix. Or you can enumerate the keyboard mapping yourself with XGetKeyboardMapping() and call XKeysymToString() on each KeySym. You probably don't need to explicitly send Alt/Shift/etc events; simply setting the state field in the XKeyEvent structure should suffice. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Re-mapping the middlemouse paste functionality
Adrian Sud wrote: I am trying to reconfigure the middle mouse button paste buffer command to another one of the 7 available buttons on my mouse, but leave the 2nd mouse button reporting itself as a 2nd mouse button. Any googling and browsing of FAQs finds ways to disable the 2nd mouse button entirely, or map the 2nd mouse button to another button (causing all other functions tied to the 2nd mouse button to move to that other button as well). Am I to assume that this is not a configurable thing? This may be the wrong place to ask; I am assuming X controls this middle-click paste buffer access because X is historically the controller of pointer devices. X controls which button code is reported when you press a particular physical button. The application (or, more likely, the toolkit which it uses) decides what happens when it receives a particular key or button event. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Russell Shaw wrote: Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. On the contrary, using bare Xlib you would be hard pressed to write even a trivial application within a month unless you're willing to give up a lot of features which many people would take for granted (e.g. configuration, support for multiple locales, interoperability with other applications, etc). As with many things, being different is automatically a loss, so you have to do better on the other aspects just to break even. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Widget children
LALLIER Cedric (EXT TEAMLOG) wrote: Why the resource XmNchildren and/or XmNnumChildren does not return all the widgets children of a similar widget, while Editres or XtNameToWidget indicates that the other widgets children are connected with the similar widget? XtNchildren is the list of children of a composite widget. Whether or not this includes widgets which are part of the widget's implementation is up to the implementation of the widget class. XtNameToWidget() only considers members of the children resource for Composite widgets, and popup children for non-Composite widgets. At some point, the Editres support in libXmu was changed to include associated widgets (any resource of type XtRWidget whose parent is the specified widget) along with the children. This is specific to Editres, though; such widgets aren't considered children by XtNameToWidget(). -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Widget children
Yann Droneaud wrote: Why the resource XmNchildren and/or XmNnumChildren does not return all the widgets children of a similar widget, while Editres or XtNameToWidget indicates that the other widgets children are connected with the similar widget? This is about Motif, and Motif is not part of X.org afaik, so it's probably the wrong mailing list. It's not specific to Motif. The XtNchildren and XtNnumChildren resources belong to Composite, which is part of Xt, as is XtNameToWidget(), while the Editres protocol is implemented in Xmu. AFAIK, libXt and libXmu are still part of the modular X.org distribution (the editres client was removed in 7.4 onwards). -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: silly keycode question
Nokan Emiro wrote: I need to catch all the Alt+F8 keypresses in my program, and I do it this way: XGrabKey(display, XKeysymToKeycode(display, F8), Mod1Mask, root_window, True, GrabModeAsync, GrabModeAsync); This works fine if no lock keys (ScrollLock, NumLock, CapsLock or combinations of these) are active. Which one is the nicest way to catch Alt+F8 irrespectively of the state of Lock keys? Grab F8 with all combinations of lock modifiers in addition to Mod1, i.e. 2^N separate grabs, where N is the number of lock modifiers. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: I18n text input
Russell Shaw wrote: Unless you're planning on spending the next few months learning how text entry works for languages other than English, I'd recommend using a GUI toolkit rather than trying to do it using bare Xlib. Or at least steal the code from such a toolkit. I understand everything about non-english text entry and processing. When i do: XIM im = XOpenIM(app-display, NULL, NULL, NULL); im is set to a valid XIM rather than NULL. I thought an input method was supposed to be a separate process, but i haven't started one or used one previously. Where is this one coming from? What sort of text entry can i do with it? Simpler input methods (dead keys and compose) are built into X. More complex methods (e.g. those for CJK) use a separate IM server. If your locale is for a Latin-based language, you should be able to use dead keys and compose processing. For a UK keyboard, AltGr and the rightmost keys (=[]#'/) normally act as dead keys, while Shift-AltGr is Compose. There is more information on the API in §13.5 of the Xlib manual. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: I18n text input
Russell Shaw wrote: For functions XkbLookupKeySym(), XLookupString(), XKeycodeToKeysym(), XKeysymToString etc, how can i tell if the keysym is a graphic printable character like a, or a control character such as Left (XK_Left) ? I need to tell automatically if it's a normal unicode character that can be printed in an entry box for any written language. For languages other than English, keyboard input isn't as simple as one keypress = one character. Many Western languages use dead accents (i.e. pressing an accent key causes the next character to be accented) or compose processing (e.g. Compose,o,/ = ø), and East-Asian languages typically require far more complex input methods. Do these functions return UTF-8 unicode? XLookupString() uses ISO-8859-1. XmbLookupString() and XwcLookupString() return strings in a locale-specific encoding. If X_HAVE_UTF8_STRING is defined, Xutf8LookupString() returns a UTF-8 string. All three functions require an input context (see XOpenIM() and XCreateIC() for a starting point, but you probably aren't going to work it out from manual pages alone). Unless you're planning on spending the next few months learning how text entry works for languages other than English, I'd recommend using a GUI toolkit rather than trying to do it using bare Xlib. Or at least steal the code from such a toolkit. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: About the scheduling of xorg applications
ZelluX wrote: I'm not familiar with x window system and trying to know some details about process scheduling. Considering such a situation, some applications are running on x window systems and one of them, for example, a web browser has the focus. If there comes an interrupt, such as a keyboard interrupt, and now kernel takes over the control. My question is that what's the running user-mode application now, is it the web browser, xserver, or any process is possible? A process which is busy executing user-space code is in the running state (shown by an R in the STAT field in the output from ps), which means that the kernel will allocate CPU time-slices to it on a regular basis. When a process performs a blocking I/O call (e.g. read(), select(), poll() etc for a socket, pipe or character device, and no data can be read or written), the kernel will change the process' status to interruptible sleep (shown by an S). Sleeping processes aren't allocated any CPU time. If you run ps with the l flag, the WCHAN field will give an indication as to what a sleeping process is waiting for. A running process will have a - in that field, as it isn't waiting for anything. Servicing an interrupt from a device may result in processes which were waiting for the device changing state from sleeping to running, in which case the process will start receiving CPU time-slices again. The first time-slice won't necessarily be allocated as soon as the kernel has serviced the interrupt, as other processes with higher priorities may also be in the running state. If a process is waiting on a pipe, Unix-domain socket, pty, mutex, or similar, it will be woken (changed from sleeping to running) when some other process affects its state (e.g. writes to the other end of a pipe), rather than in response to a hardware event. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XWindow without titlebar
Carlos (particular) wrote: Hello, How can I create a XWindow without titlebar (or without close button) but with window border? I've used _MOTIF_WM_HINTS atom but remove the window border. hints.flags = MWM_HINTS_DECORATIONS; hints.decorations = MWM_DECOR_BORDER | MWM_DECOR_RESIZEH; Whether or not your WM respects this is up to the WM. If is not posible, how can ignore the close button event? the goal is not to close the window from the titlebar. Add WM_DELETE_WINDOW to WM_PROTOCOLS. This will typically case the WM to send a ClientMessage event with WM_DELETE_WINDOW as the type atom, rather than simply destroying the window. The application can simply ignore the message. However, like a lot of things in X, this relies upon the WM cooperating. If the WM also provides a feature to destroy (as opposed to delete) a window, you can't prevent this. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: disable export:DISPLAY
strat...@telenet.be wrote: On multiseat/multi-users system there are multiple users logged in via gdm.Problem is that a user can start programs or take over a display from another user.How to prevent this?I have read about mit-magic-cookie but did not found a howto. Use user-based (xauth) access control rather than host-based (xhost). This should be the default if the server is started by a display manager, unless you explicitly allow host-based access via xhost (which you shouldn't do for a multi-user system). I can't comment on GDM specifically (I don't use it, and the documenation is silent on this issue), but it's possible that either GDM or the default startup scripts perform the equivalent of xhost +local: or xhost +inet:localhost. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How on earth do you set your screen res after a crash??
Luke Benstead wrote: I guess this looks like a bug with the OpenGL libraries rather than an XOrg one after all, as I would assume the OpenGL libraries would restore the video mode if the application terminated unexpectedly. I think it is a bug with Xorg. The way I see it, an application shouldn't be able to leave the resolution in an undesired state, if an app crashes you should revert back to your chosen resolution. It's a limitation rather than a bug. I've brought this up before, Windows has a concept of a temporary resolution change, if the app crashes the resolution is restored. I think Xrandr should have such a feature, where a resolution change is attached to the application window (although I have no clue about the technical issues with that). If an application crashes, or is alt+tabbed away from, the resolution should restore, although I don't know what level in the stack should take care of that. If the resolution is associated with a window, that's something the WM could take care of. E.g. the client attaches a full-screen property to the window; whenever the WM considers that window to be active, the screen resolution would be set to the window's size (or rather the smallest available resolution large enough to contain the window), the window (sans decorations) would be centred on screen, and all other windows would be hidden. The WM would revert the changes when the window is no longer active or no longer exists. There's a chicken-and-egg problem in that WMs aren't likely to support this feature if nothing uses it, and until it's widely supported, applications wanting full-screen will have to do it themselves. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How on earth do you set your screen res after a crash??
Adam Nielsen wrote:
Please let me know if anyone knows how to change X11 screen resolutions
without closing down everything and restarting.
The following uses XFree86-VidModeExtension:
/* make xvidmode CFLAGS='-Wall' LDFLAGS='-L/usr/X11R6/lib' LDLIBS='-lX11
-lXxf86vm -lXext' */
#include X11/Xlib.h
#include X11/extensions/xf86vmode.h
#include stdlib.h
#include stdio.h
int main(int argc, char **argv)
{
Display *dpy;
int num_modes;
XF86VidModeModeInfo **modes;
int width, height;
int i;
XF86VidModeModeInfo *best_mode = NULL;
if (argc != 3) {
fprintf(stderr, Usage: %s width height\n, argv[0]);
return 1;
}
width = atoi(argv[1]);
height = atoi(argv[2]);
dpy = XOpenDisplay(NULL);
if (!dpy) {
fprintf(stderr, Unable to open display\n);
return 1;
}
if (!XF86VidModeGetAllModeLines(dpy, DefaultScreen(dpy), num_modes,
modes)) {
fprintf(stderr, Unable to query modes\n);
return 1;
}
for (i = 0; i num_modes; i++) {
XF86VidModeModeInfo *mode = modes[i];
if (mode-hdisplay width || mode-vdisplay height)
continue;
if (best_mode (mode-hdisplay best_mode-hdisplay ||
mode-vdisplay best_mode-vdisplay))
continue;
best_mode = mode;
}
if (!best_mode) {
fprintf(stderr, Unable to find a suitable mode\n);
return 1;
}
XWarpPointer(dpy, None, DefaultRootWindow(dpy), 0, 0, 0, 0, 0, 0);
XF86VidModeSwitchToMode(dpy, DefaultScreen(dpy), best_mode);
XF86VidModeSetViewPort(dpy, DefaultScreen(dpy), 0, 0);
XFree(modes);
XCloseDisplay(dpy);
return 0;
}
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X ports?
Alan Coopersmith wrote: Does the X protocol use specific IP ports? TCP port 6000 + display id, i.e. :0 = 6000, :10 = 6010. Also, UDP port 177 for XDMCP, but you probably don't need that (it's mainly for dumb X terminals). -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Mapping combo to key and key to combo
Matthijs Kooijman wrote: This would mean I would have to set mapping per each application, undoable. I need something more low-level, system-wide, to fool any app that I am really pressing the assigned keys. Perhaps this should be achieved by an application that catches key presses, eats them and insert synthetic keypresses back into X? Not sure if this is exactly how it should work, or if there is already an app doing this... Most WMs include a feature to grab keys and associate them with commands. FVWM also has a FakeKeypress command, but I couldn't mangage to get this to work for modified keys. Also, sending key events from an application will cause the event to have the send_event field set, which allows the application to distinguish a fake event from a real event (e.g. xterm ignores events with the send_event field set unless the Allow SendEvents option is enabled). It may be possible to use the XTest extension (i.e. XTestFakeKeyEvent) if you need to generate events which don't have the send_event field set. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Mapping combo to key and key to combo
Thomas Dickey wrote:
I think maybe xmodmap or xbindkeys might be able to do something like
that.
Perhaps - but the windows-key may be a problem (iirc, unless _it_ happens
to be one of the special modifiers such as shift- and control-, it won't
work - someone might be able to clarify that).
Usually the Windows key gets mapped to Super, which, in turn, is usually
Mod4.
man xmodmap says
keycode NUMBER = KEYSYMNAME ...
The list of keysyms is assigned to the indicated keycode
(which
may be specified in decimal, hex or octal and can be
determined
by running the xev program). Up to eight keysyms may
be
attached to a key, however the last four are not used in
any
major X server implementation. The first keysym is used
when
no modifier key is pressed in conjunction with this key,
the
second with Shift, the third when the Mode_switch key is
used
with this key and the fourth when both the Mode_switch
and
Shift keys are used.
...from which I recall some comment that indicates that while you can
assign any key to be one of the extra modifiers, it's only the first
four in this table that can be received as a completely-reassigned keysym.
Otherwise, you're relying on the application to interpret the modifiers
(as xterm does, for example - in addition to the translations resource).
That wouldn't be what OP was requesting.
clarification on this point was what I was suggesting...
I think that Marius interpreted your previous comment as simply saying
the Windows key has to be bound to a modifier to use it like a
modifier, rather than saying it has to be one of the `special'
modifiers in order to have it affect the keysym.
As the xmodmap section cited above says, the only modifiers which
affect the keycode-keysym mapping are the shift modifier (and the
{num,caps,shift}-lock modifiers) and the Mode_switch/ISO_Level3_Shift
modifier. These are the ones which are used to select between the
multiple symbols which may be printed on a physical key.
The use of Shift/AltGr to affect the keycode to keysysm translation
allows libraries and applications to handle text input without needing
to know the details of the various keyboard layouts (e.g. Shift+2 is
atsign on a US keyboard but quotedbl on a UK keyboard).
XLookupString() etc can just look at the keysyms without worrying
about where they came from.
Modifiers not related to text entry don't affect the keysym, but are
simply reported as modifiers in the event structure. (However,
modifiers which *do* affect the keysym are also reported as modifiers,
so applications which do their own low-level event processing need to
know that Shift+! == ! == Shift+1).
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there a chance to set an alpha-mask using XOrg?
Leif Bergerhoff wrote: It depends on your toolkit. If you're not using any particular toolkit, the easiest way is to set _NET_WM_WINDOW_OPACITY on your window. See http://webcvs.freedesktop.org/xapps/transset/transSet.c?view=markup for an example. Make sure a composite manager is running (many desktops run one by default these days). No, I don't want to make use of a toolkit if possible. As I can see I would have to make use of the composite extension. If I remember correctly, I read about this extension supporting max. 2 output devices. Right? This would mean, I'll need another way for setting an image as an alpha-mask, since I want to make use of 6 output devices. If you just want rendering functions which support translucency, use Cairo (you can use XRender directly, but there's unlikely to be any advantage to doing so). The core X protocol doesn't support alpha blending; apart from anything else, it's only meaningful with StaticGray and TrueColor visuals. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Matching client windows by resource IDs
Christian Pirchheim wrote:
Wonder if there are client-side functions which allow to retrieve resource
mask
and base XIDs (as defined in the _XDisplay struct) given only a particular
resource (e.g. Window) XID. IOW: Are functions available, which have
signatures
similar to:
void XGetResourceMaskAndBase(XID resource, XID *mask, XID *base);
Not quite; libXRes has:
typedef struct {
XID resource_base;
XID resource_mask;
} XResClient;
Status XResQueryClients(Display *dpy, int *num_clients, XResClient **clients);
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Window Managers and XGrabKey*()
Bedő Sándor wrote: I have an academic question about X Window Managers. So I think the idea of grabbing the keyboard is wrong... Yep. 2) My next idea was to grab only the desired keys with the Xlib function XGrabKey(). This is the way I implemented my Window Manager, and it works fine with a couple of other X clients, like xterm, or firefox. But there are a few other clients, that use XGrabKeyboard, and in case these applications get the focus, and appropriate the keyboard, my Window Manager does not get the desired keystrokes. Hmmm, maybe grabbing the whole keyboard in the Window Manager is not such a wrong idea? Clients usually don't care about the return value of the XGrabKeyboard() call (as I can see in the source of a few apps), so they always would think that they have the keyboard grabbed, even if they did not. How it is possible to implement an always working window switching key in my Window Manager, even if a client grabs the keyboard? Maybe there is an Xorg extension, or a tricky Xlib function, that makes it possible... Or the problem is that I've read an ancient documentation about the Xlib? No, your goal is wrong. If a client calls XGrabKeyboard(), it should receive all keystrokes, even the ones which your WM would normally process. You just need to accept that WM keystrokes won't work while the keyboard is grabbed. E.g. if the grab is made by a screensaver which requires a password to unlock the display, it's rather important to ensure that someone can't just walk up to the system and bypass the screensaver via WM hotkeys. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
Xavier Bestel wrote: The main benefit of a grab in the use of menus is that you will get the next event regardless of where it occurs. This is what makes the menu disappear when you click elsewhere. If the application didn't grab, the menu could only disappear by activating a menu item, or - assuming the application supports this - by clicking elsewhere in one of the application's windows. Just as a datapoint, AFAIK that's how Windows GUI toolkits work. They don't grab the whole display, thay just wait for events in their window. Windows isn't X. On Windows menus are a distinct class of GUI object, distinct from a Window. On X, a menu is just a window, and the application needs to use a grab if it wants to close the menu when a click occurs outside of the menu. Any suggestions on solving this feature through other means is appreciated (note that registering for events on every visible window doesn't count). Limiting events to the application windows doesn't seem that bad. That would mean that menus persist until you click in a window belonging to the application which created the menu. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Jim Gettys wrote: Note, however, that our concept of size of fonts is fundamentally broken: the physical size in pixels of some physical size is *very* seldom what you actually want; what you really want is the size of a font in terms of angle: the physical size at some distance. As well as a minimum physical size based upon viewing distance and eyesight, you also need a minimum number of pixels, regardless of the size (subtended angle) of those pixels. Satisfying the former constraint doesn't automatically mean that you will satisfy the latter. Also, it's not as if either minimum is an absolute. There's a difference between being able to read something and being able to read it comfortably. Between the two, other factors may come into play. If I'm reading text formatted to e.g. 80 columns, and the comfortable size only gives me 70 columns, a slightly smaller font would almost certainly be preferable. An obsession with physical size makes no more sense than an obsession with pixel sizes. Actually, it makes less sense. At least the historical fixation on pixel sizes had a rational basis: rescaled bitmaps look so bad that they're almost never useful. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: PseudoColor and DirectColor visuals (was Re: Documentation?)
Patrick O'Donnell wrote: So much stuff breaks with a DirectColor visual that no-one ever uses one. By this, I presume you mean that many clients fail to support DirectColor correctly, (or fail to match visuals correctly) so they break? Or are you referring to server support for DirectColor failing often? Clients. Either they print a not supported error message, or just assume that the default colourmap has full-scale monotonic ramps and treat it as TrueColor. If you're really lucky, they'll allocate a private colourmap, set linear ramps, then treat it as TrueColor. The number of programs which break with a DirectColor visual suggests that they're essentially a theoretical concept which doesn't occur in practice. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: PseudoColor and DirectColor visuals (was Re: Documentation?)
Patrick O'Donnell wrote: Speaking of which -- the applications I'm maintaining are wedded to using a writable color map, which has always been PseudoColor, which, as you point out, pretty much means 8-bit. I've been toying with expanding the apps' repertoire to accepting a DirectColor visual, but I've noticed that not a lot of servers actually offer one. Would I be wasting my time adding in the necessary support for DirectColor? Probably. So much stuff breaks with a DirectColor visual that no-one ever uses one. The main problem with relying upon a PseudoColor visual is that the hardware support could quite quickly go the way of floppy drives and serial and parallel ports. The only reason the chipset vendors still provide hardware VGA compatibility is that safe mode relies upon it. If they ever figure out how to eliminate that requirement, the video palette will disappear overnight. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Mark Wagner wrote: I'm busy updating the Linux branch of a cross-platform toolkit that was last updated in 1994. The big problem I'm running into is a lack of documentation on how to program for XWindows: the online documentation I've been able to find is at least as old as the toolkit -- for example, one has an appendix detailing the changes from X11R4 to X11R5. Other webpages I've found may be newer, but they don't mention any dates or versions. Is there a good online document on how to program for XWindows using Xlib? Are there programming references for the various extensions, or do I need to work from protocol specifications and uncommented header files? http://www.x.org/docs/ -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Ross Burton wrote: I can't believe I'm feeding the troll, but in GNOME (and KDE I'm sure) there is a nice big Antialiasing: off button in the font configuration. And where is the Prefer legibility over getting the exact physical size to within a nanometre button? -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Patrick O'Donnell wrote: that need root access to modify. That or an ability to read documentation. Hmmm.. It seems to me that that's how this thread started, and the original question has yet to be answered. Someone offered up www.x.org/docs, which may be fine for X Window System developers, but is not what most application programmers would call documentation. Oh? Would you care to elaborate? Like, what is *actually* missing? I have made similar queries on this list for documentation, with similar lack of results. IOW, you ask, people answer, you don't like the answer (probably because you didn't ask the right question in the first place), then claim that no-one answered. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: how can I know cursor in an editable field?
marslee_suc wrote: I am working on an onscreen keyboard, I want it can call itself when end-user click an editable field such as editline or text field when focus leave editable field keyboard can hide itself. what should I do, I think X can know If user enter an editable field, but I don't how to deal with it. X itself knows nothing about widgets or fields. These are constructed by the toolkit (GTK etc). Also, with lightweight toolkits (which, IIRC, includes the latest version of Qt), X doesn't even have any clues about how a window is divided up, let alone definite information. Realistically, you are going to need to handle each toolkit separately, possibly even modifying the toolkit. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How does X Server assign Window ID?
Sheng Yu wrote: I tried generating two windows and draw on the second window in displays ':2.0' and ':2.1'. This makes the window id used for rendering different from the windows in displays ':1.0' and ':1.1'. And it works! The function glXMakeCurrent() does not crash, and the rendering also seems to be correct. I looked into the source code of GLX, and I cannot find any clue that the same window id will cause this function to crash with a segmentation fault. Could it be possible that it is a bug in the graphics driver? Your findings suggest that something may be treating window IDs as being unique globally rather than per-display. If you're using a proprietary OpenGL driver, that would be a prime suspect. Try forcing indirect rendering with AIGLX disabled (and without nVidia's libGL, if you're using that). -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: how to display a XImage with 16bits depth in a drawable with a depth of 24bits ?
hd wrote: I my app, I receive a raw image in 16 bits depth. My defaut visual have a depth of 24 bits (and all other Visual have 24 or 32bits depth on my X server). To display the bitmap I try to create an XImage with XCreateImage() and display it with XPutImage(). But X displays a bad match error If I try to display a raw image with the same depth (24bits) as the visual (24bits), my app works. Question : XImage APIs (XCreateImage() / XPutImage() / ...) can convert 'on the fly' the depth of the bitmap to match the visual depth or must I convert myself the raw bitmap to match the visual depth ? (convert each pixel from 16bits to 24 bits) You must convert yourself, or use a higher-level interface. The core X protocol doesn't do format conversions. If you want the conversion to be done in hardware, look at OpenGL or XRender. It's implementation-dependent whether either of these supports a specific format (other than 24-bit RGB), so you still need to provide a software conversion. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xclock's problem
Masaru Nomiya wrote: Subject: Re: xclock's problem Message-ID : 18855.23177.348554.585...@cerise.gclements.plus.com Date Time: Fri, 27 Feb 2009 03:14:17 + [Glynn] == Glynn Clements gl...@gclements.plus.com has written: Me I'm using xlock with the settings in .xinitrc; Me Me xclock -digital -update 1 -fg gray100 -bg gray25 -fn -*-*-bold-r-normal--16-* -geometry 270x33+1642+0 -strftime %Y年%m月%d日(%a) %H時%M分%S秒 Glynn I don't know if it's related to your problem, but you should probably Glynn be using e.g.: Glynn-xrm *fontSet: -*-*-bold-r-normal--16-* Glynn instead of -fn. Glynn Also, try using the -norender option. Thanks. With -xrm and -norender, I can use my favotite font. But, how do you know -xrm option? It is not in man, nor massage by executing xclock -h. It's a standard option implemented by the X toolkit (Xt). Similarly, the fontSet resource is standardised by the Athena (Xaw) widget set which xclock uses. When xclock was written, it was probably assumed that users would be familiar with this. As other toolkits have become more popular (primarily GTK and Qt), users are less likely to be familiar with the X toolkit and X resources Anyway, a problem of time display is a bug, isn't it? Probably. AFAICT, the problem relates to the code which only redraws the portion which has changed (which seems like needless optimisation to me). It's complicated by the fact that there are three different versions of the text handling code: Xft, multi-byte (using fontSets) and unibyte (using fonts). -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xclock's problem
Masaru Nomiya wrote: I'm using opnSuSE 11.0, whose xorg is; xorg-x11-7.4-14.1 I'm using xlock with the settings in .xinitrc; xclock -digital -update 1 -fg gray100 -bg gray25 -fn -*-*-bold-r-normal--16-* -geometry 270x33+1642+0 -strftime %Y年%m月%d日(%a) %H時%M分%S秒 I don't know if it's related to your problem, but you should probably be using e.g.: -xrm *fontSet: -*-*-bold-r-normal--16-* instead of -fn. Also, try using the -norender option. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Xlib] Saving state before an unmap
Andrew Troschinetz wrote: I realize that all I can do is set hints and make requests. However those actions have concrete results in terms of WM response. The only thing that matters to me is figuring out exactly how to prod the WM in such a way as to get the responses I need. You can't. You set hints and make requests; how (and even if) the WM responds is up to the WM. The relationship between the hints and the end result is intentionally vague. Window Managers are not non-deterministic, though they may be complex and vague. They may as well be non-determistic, as you don't have access to all of the information which controls their behaviour. When a WM purports to support the EWMH specification, I would except near compliance with that specification and *nothing more*. Bear in mind that compliance simply means that they interpret the requests correctly, not that they necessarily honour them. I am operating within the confines of those specifications and their implementations. It frightens me somewhat that you find that unsettling. What some of us are taking issue with is the remarks from your original post, some of which suggest that you have quite specific expectations about the WM's behaviour, e.g.: Basically I want to unmap a window, fiddle with it a bit (like removing the border, removing the maximize button, etc...) and then remap it. The problem I'm running into is that unmapping the window results in unintended side-effects. If unmapping the window has unintended side effects, so be it. You make a request (unmap the window), the WM does as it sees fit. What's the problem? Also: Essentially, I'm writing a window-manager-lite on top of a real window manager so that I can manipulate all the windows of all the disparate applications of the software suite I'm developing in various ways. Either you're writing a WM, or you're not. Utilities such as pagers are typically tied to a specific WM, even to the point of being part of the same source package as the WM. Probably because the global conventions don't provide the mechanisms necessary to write a pager which works reliably with any WM. And: Essentially the use case is that the user may at any point command the window of another application to remove (or un- remove) its border/close-button/etc, and I need to respect as much of the current window state of the target window as possible (ie: _NET_WM_STATE and possibly other Extended Window Manager Hints properties that I haven't even thought of yet.) The first part is simple enough: server-side resources such as windows aren't really owned by clients, beyond the fact that they will normally be destroyed when the client terminates. Any action you can perform on a window which you created can be performed on a window which another client created. The hard part is that the creator may have its own ideas about how it wants the window managed, and not all of that information will be visible to you. Some of it may only exist in the form of the program logic which determines how the client responds to events relating to the window. The only information which the client is likely to make visible is that which the standards require it to make visible in order to achieve its goals. If the window gets minimised, maybe the client will do something in response, maybe it won't; who knows? The fact that the _NET_WM_STATE property is cleared when the window is withdrawn isn't a problem. If the client subsequently decides to re-map the window, it will set this property accordingly before it does so. Okay, so your program doesn't know how the client intends to set it (if the client even handles this situation), but the standard wasn't written with your program in mind. For the case where it's the WM (in the broadest sense, which would include WM components such as pagers) which is messing with the window, there isn't a problem either. The WM knows exactly which properties it understands and what it does with them, so it can preserve or modify those as necessary. Your program doesn't know about any of that, but ... such is life. What exactly do you think the mechanism is for raising a window when the user clicks on its proxy on a panel like gnome-panel? Without looking, I would think that the mechanism would be to call either XMapWindow() or XMapRaised(). What the WM does about that is anyone's guess. Look guys, GNOME *has* the functions gtk_window_set_decorated() and gdk_window_hide(). I am not trying to do something out of the ordinary here. I'll thank you kindly to stop imposing your assumptions on me. There's a big difference between using the standard APIs and what you outlined in your original post. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Xlib] Saving state before an unmap
Andrew Troschinetz wrote: I think you should try to find somewhere a good description of what a window manager is, and specifically why it has 'manager' in its name - it is the window manager that is eventually in control of the windows and not the other way around. The more complicated things you try the more likely is that the window manager will have a different idea about it, so I suggest you instead consider to try to add your wanted features to your favorite window manager. Sigh. It's not productive for anyone here to be condescending. If that's what you call saying that things are the way things are. The window manager is eventually the one in control of all the windows, hence the name, and applications just give hints and requests. It is up to the WM to decide what to do with those and whether at all. I'm sorry that somebody told you to dig a garden with a pole, if the window managers you will use will be lenient enough and you will not want too complex things it may work with enough hacks, but it still doesn't change anything about the fact that you're trying to dig a garden with a pole. But if you want to find out on your own, fair enough. I don't believe the point you're making in any way addresses my expressed goals. I would point out that 99% of the library I've written to solve the issues I'm facing is exactly the functionality of GNOME libwnck. From the description of the project libwnck is meant to be used to implement pagers, tasklists, and other such things. Which is essentially what I'm trying to do. You wouldn't call being able to raise a window by clicking on its icon in a pager digging a garden with a pole, would you? That depends upon whether you're letting the WM do this or trying to do it yourself. Well instead of a pager I have a menubar, it's not that different. However libwnck is for GNOME, I am attempting to do something lower- lever that will work (whenever possible or fail silently) on GNOME and Motif (at the least -- however I would like to note that I have done some cursory testing on KDE as well and it seems to work fine there too). I realize that all I can do is set hints and make requests. However those actions have concrete results in terms of WM response. The only thing that matters to me is figuring out exactly how to prod the WM in such a way as to get the responses I need. You can't. You set hints and make requests; how (and even if) the WM responds is up to the WM. The relationship between the hints and the end result is intentionally vague. I'm sorry if it horrifies you that I'm making my WM work for me, rather than against me. It's not *your* WM, it's the user's. The desktop is a shared resource; it doesn't belong solely, or even primarily, to your application. Your application makes requests which the WM may or may not honour, depending upon competing requests from other clients, user configuration, and a zillion other factors. The best that you can do is to learn how to speak the WM's language, so that you can ensure that your requests are heard and understood. You cannot ensure that your requests are honoured; this is deliberate. The only way to obtain complete control is to write a WM. You cannot realistically expect to force another WM to bend to your will. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: memory leak?
DM wrote: Today I clicked in firefox 3.0.6 (fedora 10 / gnome / yum-updated / amd64 / 2GiB main memory / no swap) on http://de.wikipedia.org/wiki/Datei:Www_Beo_cc.jpg this URL: http://upload.wikimedia.org/wikipedia/commons/f/ff/Www_Beo_cc.jpg Download took quite long and the box' responsiveness was not as good as usual... So I clicked the close-window box in the title of the firefox window. The firefox window disappeared and the process, too. But the box had just 10% free main memory now (usually 80% r free after a fresh login); Xorg used 1.8GiB according to ps. So I installed xrestop, which told me that about 2 pixmaps (20MiB) belong to an unknown process. 1. xrestop (and X generally) doesn't deal with processes, but clients. Is it possible that a client spawned a child process which inherited the X connection and still exists? The X server won't free resources until the corresponding connection is closed, which only happens when *no* process has a descriptor for the remote end of the connection. 2. 20MiB isn't significant; it's ~1% of your main memory. What is significant is that the X server needed to enlarge its heap, and is now keeping hold of that memory in case it needs it in the future. This wouldn't normally be a problem, as it will just get swapped out if it isn't being used. Except that you say that you don't have any swap. Normally it takes a day until the Xorg process (VSZ RSS: 431952 88772 -- 474472 123508) and other processes get too large. Then I log off and in and everything is OK again. How can I avoid that logoff/login procedure? Add swap. Then, any memory which is allocated to the X server but isn't actively being used will get swapped out, allowing the physical memory to be used for something else. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XtDisplayToApplicationContext fails with Error: Couldn't find per display information
Tristan Schmelcher wrote: Hello all. Sorry if this is not the right place to send this, but I'm developing a plugin for Firefox on Linux and I've run up against a roadblock. In my plugin I'm being passed a pointer to an X Display struct (in NPP_SetWindow, for those of you that know NPAPI) and I'm calling XtDisplayToApplicationContext on it to get an app context to use in various Xt calls. Now on most systems this works fine--e.g., Ubuntu Dapper 32-bit with FF2 and Intrepid 32-bit with FF3 both work flawlessly. However, when I build a 64-bit version and try it on Ubuntu Hardy 64-bit with FF3, it doesn't work. When it enters XtDisplayToApplicationContext, I get Error: Couldn't find per display information on the console and the program exits. Does anyone know what could be causing this function to fail? I searched the web but without luck. AFAIK, the display must have been registered with Xt via XtDisplayInitialize(). With a conventional Xt-based application, this is done by e.g. XtAppInitialize(). Firefox isn't an Xt application, so I'm a bit surprised that it works at all. However, digging deeper I see that libxul.so uses Xt: $ nm -D /opt/firefox/libxul.so | fgrep ' U Xt' U XtAddEventHandler U XtAppCreateShell U XtAppPending U XtAppProcessEvent U XtAppSetFallbackResources U XtCreateApplicationContext U XtDestroyWidget U XtDisplay U XtDisplayToApplicationContext U XtManageChild U XtOpenDisplay U XtRealizeWidget U XtRegisterDrawable U XtRemoveEventHandler U XtSetValues U XtShellStrings U XtStrings U XtToolkitInitialize U XtUnrealizeWidget U XtUnregisterDrawable U XtVaCreateWidget U XtWindow U XtWindowToWidget XtOpenDisplay() calls XtDisplayInitialize(), so if it's getting the Display* from there, it should work. If the Display* comes from elsewhere (e.g. Gtk/Gdk), it probably won't. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: save-under support
Patrick O'Donnell wrote: Date: Fri, 23 Jan 2009 01:44:24 + From: =?UTF-8?Q?Rui_Tiago_Ca=C3=A7=C3=A3o_Matos?= tiagoma...@gmail.com 2009/1/22 Patrick O'Donnell p...@ascent.com: I've been told, recently, that save-under and backing-store under 8-bit [visuals] are no longer supported in recent X.org releases. ... could someone point me to where I would find more authoritative information on the status of save-under and backing-store? http://cgit.freedesktop.org/xorg/xserver/commit/?id=ae7f71a8b3d6756161e55d998d6eec37d2695c98 I'm afraid that's as official as it gets. So, I take it that backing store (and from a commit last August, save under) is being flushed, not just for 8-bit visuals, but completely. The theory seems to be that compositing will do (almost) the same thing. (It's a shame that backing store = Always is being tossed to the wind. Apparently, backward compatibilty is given short shrift in favor of prettiness.) Now, I have two additional troubles. The problem we're seeing with our application -- our main chart window (with backing store) is being left blank under where a pop-up (with save-under) had been mapped -- occurs in X.Org servers that predate the commit you pointed me to. So, the removal of backing store, and the much later removal of save under don't seem to be the proximal problem. It has always been the case that a server may or may not honour requests for backing store and/or save unders. These features are intended as an optimisation; they do not eliminate the need to redraw portions of the window in response to Expose events. Even if the server does support backing store and/or save unders in general, whether or not it preserves contents in specific cases could depend upon factors such as the overall demand for video memory. IOW, if neglecting to handle Expose events has worked until now, then you just got lucky. If you want to perform rendering only at a time of your choosing, the simplest solution is probably to allocate a suitably-sized Pixmap, draw into that, and either: a) handle Expose events using XCopyArea(dpy, pixmap, window, ...), or b) use the Pixmap as the Window's background_pixmap (the server *may* make a copy of the Pixmap, so you should call XSetWindowBackgroundPixmap() whenever you modify its contents). Second, although, in my searching, I have found mention of Composite and compositing managers, I've yet to find a sufficiently detailed explanation of what compositing is doing and how it is invoked or configured for me to understand how I should be managing our application's windows to make use of it. Another pointer to a good reference would be appreciated. I don't know enough about compositing to answer this one. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Bug in interaction between freeglut and mesa-7.3-rc2
Florian Echtler wrote: - It calls a GLX 1.3 function on a system that doesn't support GLX 1.3. Could you check for GLX 1.3 at compile time? I suppose not, but maybe there is a way? The GLX version is a property of the X server. There's no way that you can check this until the client has actually connected to an X server. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current support and roadmap for discrete graphics card hot switching
William Tracy wrote: I think a user logout-login, which at least in Ubuntu corresponds to a gdm restart nowadays, is a much leaner option than a cold reboot of the system. You only lose the opened windows, but all services like connection to internet, etc, are kept alive, so it's better than a reboot. Just thinking out loud here: If desktop session management were good enough, even open windows could be persisted. Even better would be if there were a mechanism to transparently disconnect an app from one X session, wait for X to restart, and then attach it to the new session. Probably doable at the toolkit level, but that doesn't help with all the zillions of apps written against legacy toolkits. Random idea: There are already several special-purpose X servers that run on top of Xorg supporting special magic like hardware compositing. What if there were a server that could dynamically dispatch to/from different Xorg instances? It would notice when Xorg dies, and stop sending it events. When a new Xorg launches, it would send a series of new window commands, and attach all of its clients to those windows. Right now I'm assuming that both cards would support equivalent resolutions and color depths. If not, then never mind. :-P The problem is that, in order to operate without explicit support from application code, both cards would need to support equivalent *everything*. A solution which relies upon the toolkit to do everything will only work for applications where ... the toolkit does everything, i.e. those whose interaction with X is limited to creating stock widgets using parameters which don't depend upon any hardware-dependent parameters. If the application queries the bit depth, or the pixel format, or the maximum size of a texture, or the maximum depth of the matrix stack, or any of a zillion other hardware-related parameters, you need to either: 1. add a mechanism to indicate that the parameter has changed, and ensure that applications allow for such changes, or 2. expose an interface which either the toolkit or the X server can emulate in its entirety atop a dumb framebuffer, and eat the (potentially huge) performance hit when it has to do so. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current support and roadmap for discrete graphics card hot switching
Stephane Marchesin wrote: and if you want to keep your session in between, we lack - X.Org infrastructure to hand a session from a graphics driver to another (there are a million of possible problems here) Right; like a million display parameters which a client can query, but for which there is no mechanism to request notification of changes, and thus are (implicitly) constant over the lifetime of the client. I know that the X developers don't consider incompatible changes to be completely out of the question, but if you're talking about a particular screen suddenly changing e.g. its glGet* values, I don't see that happening. And I don't think that it's realistic for the server to expose a single set of parameters for two very different graphics chips. It's more realistic to treat this as a traditional multiple-Screen setup, with the ability to enable and disable screens. Obviously, windows would have to either be opened on the appropriate screen (programs which need the 3D GPU on the screen which has one), or the application/toolkit would need to explicitly provide migration. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to move a window between screens?
Gerald Dachs wrote: How to move an application window between 2 independent (no Twinview, no Xinerama) screens of a x servern from outside of the application? Do I have to use something like xmove? It looks so over sized, because it is mainly for movement between different x servers on different machines. I suspect that it won't be so simple that I can XUnmapWindow the window, change the screen somehow and XMapWindow the window again. You can't move a window between screens. For a start, many server-side entitites (e.g. pixmaps) are tied to a particular screen, so the client won't be able to use existing pixmaps (etc) if the window was to suddenly move to a different screen. Also, the new screen may have a different depth, visual etc, and the client isn't expecting these properties to suddenly change. You either start the client on a proxy X server with mobile output (e.g. Xvnc), or this sort of thing has to be done in the client. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to move a window between screens?
Gerald Dachs wrote: You either start the client on a proxy X server with mobile output (e.g. Xvnc), or this sort of thing has to be done in the client. Too sad that it will not work, I don't believe that a proxy like Xvnc or xmove will be fast enough for xbmc showing movies, There's no fundamental reason why a proxy won't work (I'm not saying that existing options such as Xvnc will work, but that's an implementation detail rather than indicative of a fundamental problem). The proxy (or protocol) would ideally need to explicitly support e.g. Xv or OpenGL, so that you aren't forced to either use core Xlib for the output (X11 protocol proxy) or up-convert the data unnecessarily (rasterising proxy e.g. VNC). It's may still be simpler to try to persuade the application or toolkit to move its window. GTK+ (= 2.2) even includes a function for it: void gtk_window_set_screen(GtkWindow *window, GdkScreen *screen); Sets the GdkScreen where the window is displayed; if the window is already mapped, it will be unmapped, and then remapped on the new screen. However, you need to bear in mind that properties which may previously have been regarded as constant (e.g. root window, available visuals, default visual etc) will become variables if you start migrating between screens. Also, I don't know if the above will automatically reconstruct e.g. pixmaps for icons or if you will need to replace these manually. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How To Reduce/Eliminate Horizontal Tearing
Nick Nobody wrote: Can you recommend a media player that is able to use OpenGL? I've tried mplayer but even on a relatively fast cpu it can't playback the video fast enough (720p content). Unless I'm missing some magic switch that's buried deep within the man page :) MPlayer can be compiled with OpenGL support; mplayer -vo help will give you a list of supported drivers. For HD video, you really need video hardware which can take 4:2:0 YUV data and perform conversion and scaling itself. If the player has to perform conversion and/or scaling, that's going to eat both CPU and memory bandwidth. You also need to avoid exceeding any hardware-imposed limits on the size of the source data (i.e. either the size of the overlay or the maximum texture size). E.g. if the card limits textures to 1024x1024, and you try to play 1280x720 video with a driver that uses OpenGL texture mapping for scaling, the player may silently fall back to a slower driver. Finally, h.264 is far more CPU-intensive than e.g. XviD. If the player is using 100% CPU, it's possible that the decoding is the bottleneck. Try mplayer -vo null; if that uses 100% CPU, then the problem is with decoding the video rather than displaying it. -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X Server: abused or buggy?
Alan Coopersmith wrote: However, let us not dismiss this POV too soon. It is usually argued that an application that suffers from such memory fragmentation should be restarted occasionally (and, given that the Xserver runs in user space, unlike in Windoze, this is not impossible, though perhaps inconvenient in some circumstances). We could also investigate using a slab allocator approach for things like data structures that are a fixed size, to keep them from ending up between pixmaps, and hopefully reducing fragmentation that way, but that's also more work no one has signed up for. And it's unlikely to be worth the effort. Complaints about the server's memory usage tend to begin and end with pixmaps (I suppose that e.g. OpenGL display lists could consume similar amounts of memory, but that's likely to be a far less common case than pixmaps). If you want to avoid the situation where large amounts of memory are allocated for pixmaps, then can't be freed due to other data sharing the same memory, you're likely to be better off controlling the allocation of the pixmaps than trying to control everything else. A more fruitful solution would probably be to use a compacting (relocating) allocator for pixmaps (at least for pixel data; housekeeping structures don't really matter). -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 2D antialiasing?
McDonald, Michael-p7438c wrote: One of our customers thinks X has 2D antialiasing. In the old days, X had very specific pixelization rules which pretty much prohibited antialiasing for general graphics. Is there any supposrt for 2D antialiasing? The only thing I can find is using Xrender for antialiasing fonts. Anything else? The core X11 API doesn't support anti-aliasing. Anti-aliasing requires being able to interpolate pixel values, and the core X11 API treats pixel values as just numbers, without any consideration of how they map to colours (the rendering doesn't pay any attention to Visuals; if you're rendering to a Pixmap, there isn't even a Visual to pay attention to). Also, anti-aliasing tends to do the wrong thing if the GC's function and plane-mask aren't GXcopy and AllPlanes respectively. Programs which perform anti-aliasing will either be using XRender (or maybe OpenGL), or rendering client-side and blitting the end result. -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X Server: abused or buggy?
Óscar Fuentes wrote: Why should it be a KDE bug if the X server is leaking memory? I used to The KDE app told X to cache all those pixmaps. X is just doing what it was asked to. The alternative would be that it decided to kill off that client for being dumb. So in your opinion using X as a cache for 500 MB of pixmaps is dumb. I tend to agree, but it is reasonable to expect that when the app closes and the pixmaps are freed, all that memory is returned to the OS? Not really. Most applications just use malloc() and free(), or something similar. If they want memory, they try to get it from the heap. If there isn't a large enough block on the heap, they first obtain more memory from the OS in order to enlarge the heap. When they have finished using the memory, they return it to the heap. In most cases, they *won't* return the memory to the OS. It's only possible to do so under very specific circumstances: 1. If the memory was allocated via brk/sbrk, it can only be returned if it is at the end of the data segment. 2. If the memory was allocated via mmap(MAP_ANONYMOUS), it can only be returned if it is at the end of the mapped region. Usually, once an application has obtained memory from the OS, it will simply keep free memory around in order to satisfy future allocations. If it isn't being used, it will just get swapped out. In other words, is a bug that under this usage mode the memory asigned to X grows monotonically? No. Most long-lived applications have memory usage which grows monotonically, for the reasons outlined above. I put usage in quotes because they won't necessarily be *using* the memory; they'll just have it allocated (and swapped out). -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: GLX in Xephyr --or-- is there some other way to catch a desktop in a texture?
Ashi Krishnan wrote: This is fine if (1) the app creates only one window, and (2) is quite cooperative with respect to where it draws that window -- like, say, the xscreensaver hacks. Maybe I'm dense, but I'm not seeing how that's a problem. Since you're acting as the window manager (you are 'managing' that window), you can manage all the windows of the application. You can decorate and compose them however you see fit. But I want to manage all the windows of that application and *only* the windows of that application. And, as far as I'm aware, there's no reliable way of figuring out the pid of the process that owns a given window. Does _NET_WM_PID work reliably enough to be useful? If you don't actually need to know the PID, but just want to be able to distinguish one client from another, you can identify the client from the Window's XID, e.g. using XResQueryClients(). -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: how does x write to display cards
My Own Linux wrote: I am doing a small project (still in learning phase). I want to know does X server write the image to the display card memory to be shown on monitor. Does it use DirectFB or the Linux frame buffer ? It usually access the hardware directly, although there is a driver for fbdev. -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xquartz dereferencing a NULL pointer (patch 2)
Simon Thum wrote: newtail = (oldtail + 1) % QUEUE_SIZE; miEventQueue.tail = newtail; becoming miEventQueue.tail++; miEventQueue.tail |= QUEUE_SIZE - 1; Er, shouldn't this be = ? I don't think a compiler should be doing this to a non-local store. It could probably be considered a bug. C doesn't really have a memory model but few rules likely to forbid this. I didn't check, but I'd be highly surprised by this being legal. Unless an lvalue is declared volatile, the compiler is free to generate code which modifies it as and when it sees fit, so long as it has the correct value in the end. In the meantime, it can freely store arbitrary data there if it wishes. This is why the volatile keyword was added to the ANSI C standard: so that the compiler could optimise memory access as it saw fit, while providing an opt-out for the cases where intermediate values are significant (signals, interrupts, memory-mapped I/O, threads, etc). -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Transfer display of active windows remotely
Harald Braumann wrote: It is an application (or maybe toolkit) level problem: handle the event that the X display connection is being closed better than by killing the application and allow it to reconnect to a new display later (through some communication protocol). But couldn't it be done on Xlib level? Then it would work immediately for all apps. On the Xlib-level some mapping would have to be done (Atoms, XIDs, ...). Even if you were to embed the guts of a proxy X server into Xlib, there would still be plenty of issues. In particular, it would need some degree of high-level knowledge (e.g. of properties) so that it knows when it needs to perform mapping. This would require ongoing maintenance as new properties come into use. It would also preclude applications communicating X-related information via unofficial channels. And both servers would have to provide the same extensions and visuals (at least those, that are used by the app). The case when some of those are missing on the target server would still have to be handled by the toolkit. Waiting for all the toolkits to implement X roaming (there's not only GTK and Qt), will probably exceed the time the universe has left. Waiting for it to happen transparently will likely take longer, as it's a significantly harder task. Regardless of the level at which it occurs, you can't make the transfer entirely transparent unless the application is particularly simple. One of the biggest issues is the complexity and level of integration of desktop environments. Toolkits are no longer just about displaying windows. There's also integration with a whole range of services provided by the desktop environment. If you move between displays, any other clients which were on the previous display will simply vanish. Even if identical programs are running on the new display, it isn't likely to be feasible (especially at the protocol or Xlib levels) to simply establish new connections and pretend that nothing has changed. -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Transfer display of active windows remotely
David Greaves wrote: - Consider display :0 on machine 1 (m1) and display :0 on machine 2 (m2). Agreed, it's about time X supported changing the DISPLAY out from under an application. a follow-me type feature. This is something which would be far easier to achieve at the toolkit level. There are too many problems with doing it at the X protocol level. There's no guarantee that the new X server will support the visual you're using, or all of the extensions. Even if they're that similar, the XIDs which are known to the client may be in use on the new server, Atoms will have different numbers, etc. -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Transient windows
refers to a resource which the itself client created. Any direct children of the root window which don't have the override-redirect flag set will normally be owned by the WM, with the grandchildren and their descendents owned by individual clients. override-redirect windows will normally be direct children of the root window, and owned by individual clients. -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Transient windows
Juliusz Chroboczek wrote: behind the transient principle, the documentation that I've found is light and examples aren't many on the web or won't go too deep into the matter. I don't know if you have any link to suggest me, if any, I'd be glad. ICCCM, Section 4.1.2.6. The ICCCM is a complex matter, and most tutorials you'll find on the subject are incorrect. You really should read the ICCCM (as well as the freedesktop.org wm-spec) rather than trying to browse the web for information. Also, bear in mind that a lot of software simply ignores the ICCCM. The handling of Alt/Meta by certain GUI toolkits is a prime example. -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
Ben Gamari (FOSS) wrote: My completely unprofessional opinion is that Jason brings up a really good point here. Accidentally zapping Xorg can not only be extremely frustrating, but it could be extremely confusing for a new user. This being said, I also agree that any change that might be zapping unreliable or even unduly difficult is unacceptable.However, I do believe there is a better solution than what we have presently. Ctrl, Alt, and Backspace are usually three of the largest keys on most keyboards and I can personally attest to the ease of triggering on some keyboards (try typing on a laptop balanced on your knee). I think that requiring two presses of Ctrl-Alt-Backspace in close succession would be perfect, so long as a tightly looping Xorg would still register the event. Otherwise, perhaps adding Shift to the Ctrl-Alt-Backspace combination would be a reasonable course of action so long as it doesn't preclude any keyboards. If this too is not possible, perhaps making use of the Pause/Break key in replacement of the Backspace key would be workable. Ctrl-Alt-Break would be an improvement. Apart from anything else, that isn't bound to anytyhing in Emacs (which pre-dates X, BTW). For me, if X locks up to the extent that I can't quit the WM (and thus the session) normally, it is normally locked up to the extent that Ctrl-Alt-BS doesn't work either, and I need to resort to Alt-SysRq-K. Unfortunately, that tends to leave the video card in a state where consoles don't work, but I can at least use Ctrl-Alt-Del to trigger a clean reboot. -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
Russell Shaw wrote: I realized that without a window manager you get an ugly black cross cursor which isn't real useful. X should've had a default arrow cursor. IMHO, an arrow implies that it's pointing at something, i.e. clicking a mouse button will have some effect related to whatever the cursor is over, while the cross indicates there's nothing here, i.e. clicks will be ignored. -- Glynn Clements [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
