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 ___ 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: 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 ___ 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 ___ 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 ___ 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 ___ 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.
asible approaches to window "mobility": 1. VNC-like framebuffer sharing. The application connects to a specific X server which performs all rendering. You have the option to forward rendered images to other systems 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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: Create a *real* top level window
Eeri Kask wrote: > > wrongfully ignore override-redirect? they have little choice. > > x11 core has defined that they are to bypass the wm. > > no map redirects for them. dont blame wm's. > > No I don't, though it looks like the current server implementation > only ensures WMs have no advantage in knowing something about their > geometrical structure '_in_advance_' (in respect to all other > clients). I haven't read, but maybe the spec just says this. :-) Nothing prevents a WM (or any other client) selecting SubstructureNotify to obtain notification of changes, and it will receive notification regardless of the override_redirect flag. It's only the ability to "veto" changes via SubstructureRedirectMask which is limited to one client at a time, and overriden by the override_redirect flag. -- Glynn Clements ___ 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 ___ 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 ___ 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: [Nooby Question] Scale Pixmap / Image
Rashid wrote: > is there a way to scale a pixmap / image / frame buffer content with > native xlib-Code. No. The core X protocol doesn't include this functionality. You need to use an extension (e.g. XRender, Xv, GLX). -- Glynn Clements ___ 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 ___ 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 ? That's essentially Xvnc except that it uses Composite to do it window-by-window rather than for the whole screen. -- Glynn Clements ___ 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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: > > 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- 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 ___ 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: > 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 ___ 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 , 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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
___
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 ___ 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
#include
#include
#include
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 \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
___
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 ___ 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
___
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 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radical idea for X-modmap problem.
walt wrote: > I'm wondering about the connection from terminal to server, and how much > bandwidth would be typical for such a setting. (I'm assuming that college > students would spent substantial time watching X-rated videos on their > X-terminals ;-) It depends upon the application. Some inherently generate a lot of traffic, others generate unnecessary traffic due to the author(s) not understanding X. -- Glynn Clements ___ 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 ___ 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
___
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 ___ 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 ___ 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 ___ 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 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Mark Wagner wrote: > >> Thanks. Is there any documentation on the best way to do various > >> high-level tasks, such as drawing images? > > > > As already discussed, for higher-level tasks you'll be better of going > > through a higher-level library such as cairo. > > > > cairo is not listed proeminently as an X component, because it also > > works on non-X systems but it is a core library for anything doing GUI > > stuff under X nowadays (with the exception of QT apps, but QT has a > > wider scope than cairo) > > How standard is Cairo? The proof-of-concept app from 15 years ago > still works fine because it's only got two dependancies: Xlib and > libc. It works everywhere for the same reason. If I added Cairo as a > dependancy, would apps still work on 100% of Linux systems, and would > they still work unmodified 15 years from now? I would guess that your 15-year-old app has a looser definition of "works" than is the norm nowadays. E.g. how well does it work in CJK or right-to-left locales? What about accessibility? Session management? Is it usable on a 200 DPI display? Having said that, modern applications aren't exactly immune from adjusting requirements according to ease of implementation. Try using some on a remote display with 500ms lag. [The "Clueless Idiot of the Year" award goes to the PyOpenGL developer who thought that raising a Python exception for any OpenGL error was a good idea.] -- Glynn Clements ___ 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 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
of the details, particularly if it is cross-platform. The low-level documentation is of interest mainly to authors of toolkits and/or low-level utilities. -- Glynn Clements ___ 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 ___ 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 ___ 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 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Replacing a window icon in X11?
Wirawan Purwanto wrote: > Today most window managers has an area on the top left corner of the > window decoration which shows a small bitmap, which in Windows world > called "icon". I wonder if there is any way for an external program, if it > knows the window ID of a given X11 window, to change that image to > something else. Older X programs such as xterm seems to not have an option > to set this icon pixmap (or did I miss it?). If I have a lot of such > programs open, then the "task bar" of desktop managers (xfce/gnome/kde) > only shows a bland box or "X" icon, which is not meaningful. I wonder if I > can replace that with a more suggestive pixmap, thus speeding up my search > for a particular window. > > I am quite uneducated about X11 programming, so if you can give me the > subroutine name, header file, and pointer to more information, I'd > appreciate it. If it can be accomplished using gtk, I'm fine, too. The property in question is WM_HINTS, which is set using the XSetWMHints() function. The property contains multiple fields, so in order to preserve any existing hints, you would need to read the existing value with XGetWMHints(), modify it, then write the updated value. But as Daniel suggests, most window managers provide a mechanism to override a window's icon (or lack of one). This would normally be preferable to modifying the WM_HINTS property. Apart from anything else, it's possible that your changes will be discarded whenever the application (or WM) updates the WM_HINTS property. -- Glynn Clements ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xdm, xlogin and Xresources
martin SILVERBERG wrote: > I am looking for several days on the Internet for an exhaustive list > of all Xresources classes from xdm and his xlogin widget. I have been > looking all over, and just found examples of alteration of the > original files, but no complete list. I have read the Man pages to. > They specifies that:" Nearly every imaginable parameter can be > controlled with a resource." But the list that follows doesn't give > any clue of how to modify the position of greeting or fail messages, > eventually transparency of xlogin.Login.background, border styles, > prompt frames background, etc. . The overall layout of the login widget isn't configurable, although it can be completely replaced using the DisplayManager.greeterLib resource. -- Glynn Clements ___ 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 ___ 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 ___ 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 have been tracking for a bug that makes my program crashing when > calling function glXMakeCurrent. > My program runs with multi-displays, ':0.0', ':1.0', ':1.1', ':2.0', > ':2.1'. When glXMakeCurrent() is called > to switch rendering context from ':0.0' to either ':1.0', ':1.1' or > ':2.0', ':2.1', the program runs fine. > However, if the rendering context is switch from ':1.1' to ':2.0', > the program crashes with with a > segmentation fault. > > The interesting thing I found when debugging is the window ID and > root window ID for each display: > display:':0.0',screen: 0, root window id: 315, window id: 71303171 > display:':1.0',screen: 0, root window id: 595, window id: 2097156 > display:':1.1',screen: 1, root window id: 597, window id: 4194308 > display:':2.0',screen: 0, root window id: 595, window id: 2097156 > display:':2.1',screen: 1, root window id: 597, window id: 4194308 > > It seems that X Server 1 and 2 assign window ID with the same > strategy, which is different from X Server 0. > I am wondering whether it is causing the crashing, which indicates > problems in X Server settings. I have > been digging into the source of X Server and I cannot find how the > window ID is assigned. Could someone > tell me which file I should look into? Thanks a lot! The X server doesn't assign individual XIDs (except for resources which are created internally by the server, e.g. the root window). Each client is assigned a block of XIDs upon connection, and the client (i.e. Xlib) allocates XIDs from this block. It would be more clear if you print the XIDs in hexadecimal: display:':0.0',screen: 0, root window id: 13b, window id: 443 display:':1.0',screen: 0, root window id: 253, window id: 24 display:':1.1',screen: 1, root window id: 255, window id: 44 display:':2.0',screen: 0, root window id: 253, window id: 24 display:':2.1',screen: 1, root window id: 255, window id: 44 The most significant 11 bits of the XID indicate the client, leaving 21 bits for each client, giving each client 2^21 (= 2,097,152) XIDs. In any case, I doubt that this has anything to do with your problems with OpenGL. -- Glynn Clements ___ 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 +0000 > > [Glynn] == Glynn Clements 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 ___ 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 ___ 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 ___ 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 assum
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 ___ 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 ___ 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 ___ 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?= > > > > 2009/1/22 Patrick O'Donnell : > > > 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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 ___ 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: 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?
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: 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
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: Transient windows
an obtain its own resource base and mask from the "Display"
structure, e.g.:
#include
...
struct _XDisplay *priv;
...
priv = (struct _XDisplay *) dpy;
printf("self: %08x %08x\n", priv->resource_base, priv->resource_mask);
This will allow you to determine whether a particular XID 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: 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
Re: Q about fastest display methode
Aleksandar Lazic wrote: > > Xvideo (Xv) extension covers 2, 3 and 4. This allows the use of a video > > overlay if the hardware supports it, or the use of the GPU for scaling > > and/or colour-space conversion as a fallback. > > should I use xv direct or the OpenGL Framebuffer Object or both and > decide at runtime? Xv is the preferred method for displaying video. Other mechanisms may be useful as fallbacks if the server doesn't support Xv (for cards which lack a video overlay, the driver will often still provide Xv support via the textured video), or if the Xv support is broken. > >This provides a substantial performance gain over converting to RGB and > >rescaling in software. It may also provide better quality (cards which > >provide a video overlay often have a rescaling filter which is much > >better than anything that would be feasible in software). > > How about the new cards which are desigend for DirectX10, does they > offer such 2D Acceleration? All modern cards provide features which can be used to accelerate video. At a minimum, any modern card will support image rescaling. Also, even if the card doesn't directly support YUV (technically YCbCr) images, you can usually still perform the conversion by rendering colourised versions of the individual channels in additive passes. By "modern", I mean anything that's still sold and almost anything that's been sold in the last five years. > >> 6.) I think I don't need the 3D functions of the cards. > > > >Video players often provide the option to use OpenGL for video display, > >in cases where the X server supports GLX but not Xv (or in case Xv > >support is broken). > > Due the fact that I'am not uptodate, what is the 'best' solution for the > Mainstream cards at that time? First, support Xv. Support for other rendering mechanisms depends upon how important you consider fallbacks to be. -- Glynn Clements <[EMAIL PROTECTED]> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AIGLX and direct rendering
Lars Oliver Hansen wrote: > thanks to your list members I have direct rendering working > now. I "wanted" this as it "sounds" faster than indirect rendering for > 3D games and as I read that it is required for Compiz. However AIGLX > is supposedly needed for Compiz too. Now AIGLX is "Accelerated > Indirect GLX" and I again supposedly needed the setting > LIBGL_ALWAYS_INDIRECT=true. For a 3D game I have a script which > unloads Compiz and replaces it by MetaCity. If direct rendering is > faster, is it possible to unload AIGLX or disable it for the > game? If you request a direct rendering context, and the server supports it, you should get it. Whether or not the server also accelerates indirect rendering (i.e. AIGLX) isn't relevant. -- Glynn Clements <[EMAIL PROTECTED]> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
