of
GLX_SGIX_pbuffer in the extension list. Whether a GLX visual is
double-buffered is indicated by the db column in the glxinfo output.
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org
Aaron Lewis wrote:
Hi ,
i wanted to setup default window size for xconsole program ,
although i'm on openbox , but still wanted to use Xdefaults file ,
but how ?
XConsole.width: 640
XConsole.height: 480
--
Glynn Clements gl...@gclements.plus.com
(acceleration requires local video hardware, limited by frambuffer
read speed, inter-client communication needs explicit handling, etc).
AFAICT, the only advantage is rootless operation.
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org
, only Xmux got a strong pass for
supporting cut and paste.
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo
will behave exactly like the old one, or
make the client adjust to the change. The former is somewhere between
ridiculously difficult and completely impossible, while the latter
requires significantly changing the protocol, libraries, toolkits, and
applications.
--
Glynn Clements gl...@gclements.plus.com
. The toolkit has the ability reconstruct and clone windows
at will.
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo
... or whatever
mechanism your Linux distribution uses for managing services (e.g.
something like: /etc/init.d/sshd restart).
But I don't think that will make any difference.
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org
in sshd_config, but in the absence of
some form of firewall, that will allow other hosts on the network to
connect to the X proxy.
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org
is an
IP-address), instead of the name of the computer ?
Yes.
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
the cursor keys to function keys (which
can then be rebound within minicom). Another possibility is to modify
minicom's source code. Yet another possibility is to just type literal
control characters, but that's likely to be annoying if you need to do
it a lot.
--
Glynn Clements gl...@gclements.plus.com
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
-process basis (e.g. if
DISPLAY points to a remote display and the default libGL can't handle
that).
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http
Burton Samograd wrote:
I was wondering if there was a standard way to create a window using
Xlib and have it be non-resizable (like a dialog). Would this be
through a window manager hint or something like window creation flags?
See XSetWMSizeHints.
--
Glynn Clements gl
something other than NULL as the display
argument to XOpenDisplay(). Ideally, the program should provide a
-display switch to specify the display to connect to.
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org: X.Org support
Archives
to
determine the resolution of the physical screen. This may not even be
a meaningful question, as there won't be a physical screen when no
viewer is connected, and there will be multiple physical screens when
multiple viewers are connected.
--
Glynn Clements gl...@gclements.plus.com
:(
GCs aren't associated with a window. The drawable passed to XCreateGC
is used to specify the screen and depth, but has no significance
beyond that. A GC may be used with any drawable having the correct
screen and depth.
--
Glynn Clements gl...@gclements.plus.com
.
Because it's ridiculously difficult.
Something like Xpra code.google.com/p/partiwm/wiki/xpra?
That's essentially Xvnc except that it uses Composite to do it
window-by-window rather than for the whole screen.
--
Glynn Clements gl...@gclements.plus.com
different parameters.
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch
.
Consequently, skullImage.clipmask contains the pixmap, while maskshade
contains the mask.
That causes this:
XSetClipMask(mainwindow-display, mainwindow-gc, skullImage.clipmask);
to fail, as the clip mask isn't a bitmap (1-bit per pixel).
--
Glynn Clements gl...@gclements.plus.com
);
XCopyArea(dpy, image, win, gc, ...);
The image must have all background (transparent) pixels set to zero.
Also, you can use XPutImage() instead of XCopyPlane() and XCopyArea().
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org
) is capable of sharing the card between
multiple X servers.
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your
as distinct short-lived clients. The server only
sees connections; what happens on the client side of those connections
is irrelevant.
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org: X.Org support
Archives: http
targets
(some of which may be computationally expensive to generate).
--
Glynn Clements gl...@gclements.plus.com
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org
.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
programs which
have had Xft support added (e.g. xterm) tend to use faceName and
faceSize.
Having said all that, there's no guarantee that CrossOver's font
configuration is influenced by X resources in any way.
--
Glynn Clements gl...@gclements.plus.com
.
You probably don't need to explicitly send Alt/Shift/etc events;
simply setting the state field in the XKeyEvent structure should
suffice.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http
.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
is automatically a loss, so you
have to do better on the other aspects just to break even.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
.
At some point, the Editres support in libXmu was changed to include
associated widgets (any resource of type XtRWidget whose parent is
the specified widget) along with the children. This is specific to
Editres, though; such widgets aren't considered children by
XtNameToWidget().
--
Glynn Clements gl
of the modular X.org
distribution (the editres client was removed in 7.4 onwards).
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
of these) are active.
Which one is the nicest way to catch Alt+F8
irrespectively of the state of Lock keys?
Grab F8 with all combinations of lock modifiers in addition to Mod1,
i.e. 2^N separate grabs, where N is the number of lock modifiers.
--
Glynn Clements gl...@gclements.plus.com
. For a UK keyboard, AltGr and the
rightmost keys (=[]#'/) normally act as dead keys, while Shift-AltGr
is Compose.
There is more information on the API in ยง13.5 of the Xlib manual.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg
for languages other than English, I'd recommend using
a GUI toolkit rather than trying to do it using bare Xlib. Or at least
steal the code from such a toolkit.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http
than in response to a hardware event.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
atom,
rather than simply destroying the window. The application can simply
ignore the message.
However, like a lot of things in X, this relies upon the WM
cooperating. If the WM also provides a feature to destroy (as
opposed to delete) a window, you can't prevent this.
--
Glynn Clements gl
it, and the
documenation is silent on this issue), but it's possible that either
GDM or the default startup scripts perform the equivalent of
xhost +local: or xhost +inet:localhost.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
-and-egg problem in that WMs aren't likely to support
this feature if nothing uses it, and until it's widely supported,
applications wanting full-screen will have to do it themselves.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg
);
XF86VidModeSetViewPort(dpy, DefaultScreen(dpy), 0, 0);
XFree(modes);
XCloseDisplay(dpy);
return 0;
}
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Alan Coopersmith wrote:
Does the X protocol use specific IP ports?
TCP port 6000 + display id, i.e. :0 = 6000, :10 = 6010.
Also, UDP port 177 for XDMCP, but you probably don't need that (it's
mainly for dumb X terminals).
--
Glynn Clements gl...@gclements.plus.com
is
enabled).
It may be possible to use the XTest extension (i.e. XTestFakeKeyEvent)
if you need to generate events which don't have the send_event field
set.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http
,
modifiers which *do* affect the keysym are also reported as modifiers,
so applications which do their own low-level event processing need to
know that Shift+! == ! == Shift+1).
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg
support alpha blending; apart from
anything else, it's only meaningful with StaticGray and TrueColor
visuals.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
XGetResourceMaskAndBase(XID resource, XID *mask, XID *base);
Not quite; libXRes has:
typedef struct {
XID resource_base;
XID resource_mask;
} XResClient;
Status XResQueryClients(Display *dpy, int *num_clients, XResClient **clients);
--
Glynn Clements gl
to ensure that someone can't
just walk up to the system and bypass the screensaver via WM hotkeys.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
for events on every visible window doesn't count).
Limiting events to the application windows doesn't seem that bad.
That would mean that menus persist until you click in a window
belonging to the application which created the menu.
--
Glynn Clements gl...@gclements.plus.com
certainly be preferable.
An obsession with physical size makes no more sense than an obsession
with pixel sizes. Actually, it makes less sense. At least the
historical fixation on pixel sizes had a rational basis: rescaled
bitmaps look so bad that they're almost never useful.
--
Glynn Clements gl
of programs which break with a DirectColor visual suggests
that they're essentially a theoretical concept which doesn't occur in
practice.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http
overnight.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
extensions, or do I
need to work from protocol specifications and uncommented header
files?
http://www.x.org/docs/
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman
Ross Burton wrote:
I can't believe I'm feeding the troll, but in GNOME (and KDE I'm sure)
there is a nice big Antialiasing: off button in the font
configuration.
And where is the Prefer legibility over getting the exact physical
size to within a nanometre button?
--
Glynn Clements gl
(probably
because you didn't ask the right question in the first place), then
claim that no-one answered.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
.
Realistically, you are going to need to handle each toolkit
separately, possibly even modifying the toolkit.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
window IDs as
being unique globally rather than per-display.
If you're using a proprietary OpenGL driver, that would be a prime
suspect. Try forcing indirect rendering with AIGLX disabled (and
without nVidia's libGL, if you're using that).
--
Glynn Clements gl...@gclements.plus.com
either of these
supports a specific format (other than 24-bit RGB), so you still need
to provide a software conversion.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman
Masaru Nomiya wrote:
Subject: Re: xclock's problem
Message-ID : 18855.23177.348554.585...@cerise.gclements.plus.com
Date Time: Fri, 27 Feb 2009 03:14:17 +
[Glynn] == Glynn Clements gl...@gclements.plus.com has written:
Me I'm using xlock with the settings in .xinitrc;
Me
if it's related to your problem, but you should probably
be using e.g.:
-xrm *fontSet: -*-*-bold-r-normal--16-*
instead of -fn.
Also, try using the -norender option.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg
.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
is to write a WM. You cannot
realistically expect to force another WM to bend to your will.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
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
(), so if it's getting the
Display* from there, it should work. If the Display* comes from
elsewhere (e.g. Gtk/Gdk), it probably won't.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org
would be appreciated.
I don't know enough about compositing to answer this one.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
actually connected to an X server.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
or the X server can
emulate in its entirety atop a dumb framebuffer, and eat the
(potentially huge) performance hit when it has to do so.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org
. Obviously,
windows would have to either be opened on the appropriate screen
(programs which need the 3D GPU on the screen which has one), or the
application/toolkit would need to explicitly provide migration.
--
Glynn Clements gl...@gclements.plus.com
output
(e.g. Xvnc), or this sort of thing has to be done in the client.
--
Glynn Clements gl...@gclements.plus.com
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
as constant (e.g. root window, available visuals,
default visual etc) will become variables if you start migrating
between screens. Also, I don't know if the above will automatically
reconstruct e.g. pixmaps for icons or if you will need to replace
these manually.
--
Glynn Clements gl
rather than displaying it.
--
Glynn Clements [EMAIL PROTECTED]
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
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
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
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
XResQueryClients().
--
Glynn Clements [EMAIL PROTECTED]
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
for fbdev.
--
Glynn Clements [EMAIL PROTECTED]
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
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
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
numbers, etc.
--
Glynn Clements [EMAIL PROTECTED]
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
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
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
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
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
80 matches
Mail list logo
