Re: how to convert a window ID to a linux process ID?
Perhaps some thought should be given to modify Xlib in a manner similar to the way Xt is modified with the XtDebug resource. It sets the _MIT_OBJ_CLASS property on the window with the widget instance name and the application class name.This is happening in Intrinsic.c in RealizeWidget(). This approach would allow you to get pid information in the absence of a window manager, such as when running apps rootless on a PC or in some other constrained environment. Rick -- +--+ | Rick Beldin| Hewlett-Packard Company| | email: [EMAIL PROTECTED] | Global Solutions Engineering | || 20 Perimeter Summit| +--+ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XOpenDisplay for new X Windows Programmer.
First question: Am I in the right place. I am trying to write a
simple X Window program but XFee86 seems to focus on video cards or
chips. So, if I'm not in the right place please tell me where to go but
not like my wife does.
Probably not the right place. I'm not sure but perhaps some newsgroup
like linux.dev.X11 or comp.programming.X (not sure about this one).
If this is the place, I am starting into X Window programming and I
can't even get the simplest program to run. It compiles and links fine
but always fails to make the connection to the display manager. I have
spent 2 days pouring over the internet and trying all sorts of stuff but
nothing has worked.
Don't hardcode in the string to XOpenDisplay(). Pass a NULL, and it
will use value of DISPLAY environment. I think it is probably trying
to specifically connection to port 6000 on localhost, which on your system
X may not be listening.
Your program doesn't try to create any windows.
Here is a skeleton that I use to start all my test programs:
#include X11/Xlib.h
#include X11/Xatom.h
#include stdio.h
void main(int argc, char *argv[])
{
Display *display;
Window my_window;
int screen;
XEvent event;
display = XOpenDisplay(NULL);
if (display == NULL)
{
printf(error opening display\n);
exit(0);
}
screen = DefaultScreen(display);
XSynchronize(display, 1);
my_window =
XCreateSimpleWindow(display,
RootWindow(display,screen),
100,100,
100,100,
10,
BlackPixel(display,screen),
WhitePixel(display,screen));
XSelectInput(display, my_window, 0x);
XMapWindow(display,my_window);
XFlush(display);
while (1)
{
XNextEvent(display,event);
printf(Event recieved is %d\n,event.type);
}
}
--
+--+
| Rick Beldin| Hewlett-Packard Company|
|| Global Solutions Engineering |
|| 20 Perimeter Summit|
|| Atlanta, GA 30319 |
+--+
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: VisibilityNotify/XRaiseWindow question
What is probably needed is a property on the root window that
both apps pay attention to, sort of like a mutex. The first one
to get there sets it and the other honors this request.
In the case of xlock, you have a problem since the purpose is to
lock the screen. I would think that you would have to have special
code in xbattbar to yield to xlock, since it is probably more
important to lock your screen than display your battery life.
On the hand, you might want to make that configurable.
Rick
Hi!
This is a general question on X client design. Please excuse me that
it is not directly related to the XFree86 Project.
Imagine there are two clients running the same code:
while (!done)
{
XWindowEvent(... | VisibilityChangeMask, theEvent);
switch (theEvent.type)
{
...
case VisibilityNotify:
XRaiseWindow(...);
break;
}
}
Obviously, there's a race here. Both clients are fighting to get on top.
There's a real example of this problem. One application is called
xbattbar (which is a battery status indicator), another is xlock
(used as screensaver).
What would be the right way to solve this problem?
Thanks for any answers in advance!
--
+--+
| Rick Beldin| Hewlett-Packard Company|
|| Global Solutions Engineering |
|| 20 Perimeter Summit|
|| Atlanta, GA 30319 |
+--+
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
xdmcp and clients with multiple lan interfaces...
I was looking over some recent changes to xdm in policy.c: Revision 3.9 / (download) - annotate - [select for diffs], Thu Jan 1 17:12:34 2004 UTC (12 days, 2 hours ago) by herrb Branch: MAIN CVS Tags: HEAD Changes since 3.8: +23 -2 lines Diff to previous 3.8 (unified) When handling a request paquet, select a supported connection type if possible. If no supported connection is proposed, dont reject the connection. Problem noticed by Mario Klebsch, fix by me. I've been working on similar problems where the client system (requestor) has multiple lan interfaces that are visible to the OS, yet are not configured. Such a situation can easily exist on a laptop with both wired and wireless configurations and a VPN or a workstation with multiple interfaces, one or more which are not configured. Such a situation will generate a request that appears to originate from 0.0.0.0. This situation is apparently what drove the -from option in XFree86 Xserver. While the -from is a viable workaround, I am curious as to real need for this. Consider that in xdm's xdmcp.c request_respond(): /* Check this Display against the Manager's policy */ reason = Accept (from, fromlen, displayNumber); if (reason) goto decline; /* Check the Display's stream services against Manager's policy */ i = SelectConnectionTypeIndex (connectionTypes, connectionAddresses); The from variable contains information about the requestor. It has the correct ip address of the machine that sent the request. Why aren't we simply using that address to reply back to? Why go through all the various connections? Would you want to get a request from one IP address (from) and then respond to something else (in the connectionAddresses)? I must be missing something fundamental here. In looking at this problem it would appear that a simple fix for multiple interface clients would be to simply respond back to the originator. Thanks, Rick -- +--+ | Rick Beldin| Hewlett-Packard Company| | email: rbeldinATatl.hp.com | Global Solutions Engineering | || 20 Perimeter Summit| || Atlanta, GA 30319 | +--+ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xdmcp and clients with multiple lan interfaces...
David Dawes wrote:
I'm assuming you mean that there is a 0.0.0.0 address in the
connectionAddresses list passed from the X server to the xdm server?
Yes, for example, on a Window XP laptop with lan, wireless,
and Nortel VPN software you get the following with the
internal lan connected and no wireless.
$ ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : SOMENAME
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
#thernet adapter Local Area Connection 2:
Connection-specific DNS Suffix . : some.domain.com
Description . . . . . . . . . . . : Intel(R) PRO/100 VM Network Connection
Physical Address. . . . . . . . . : 00-08-02-96-77-86
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : XX.XX.XX.XX
Subnet Mask . . . . . . . . . . . : XX.XX.XX.XX
Default Gateway . . . . . . . . . : XX.XX.XX.XX
DHCP Server . . . . . . . . . . . : XX.XX.XX.XX
DNS Servers . . . . . . . . . . . : XX.XX.XX.XX
XX.XX.XX.XX
Primary WINS Server . . . . . . . : XX.XX.XX.XX
Secondary WINS Server . . . . . . : XX.XX.XX.XX
Lease Obtained. . . . . . . . . . : Tuesday, January 13, 2004 12:24:01 P
Lease Expires . . . . . . . . . . : Monday, January 19, 2004 12:24:01 PM
Ethernet adapter {04D1B7C9-E37E-47A3-8385-BCD06ADC7AFD}:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Nortel IPSECSHM Adapter - Packet Sch
duler Miniport
Physical Address. . . . . . . . . : 44-45-53-54-42-00
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 0.0.0.0
Subnet Mask . . . . . . . . . . . : 0.0.0.0
Default Gateway . . . . . . . . . :
Ethernet adapter Wireless Network Connection:
Media State . . . . . . . . . . . : Media disconnected
Description . . . . . . . . . . . : Compaq WLAN MultiPort W200
Physical Address. . . . . . . . . : 00-0B-CD-8C-B2-A0
Note: I XX'd out all the company-specific IP addresses.
The -from option was motivated by machines with multiple configured
addresses. If an unconfigured interface address is getting added
to the list of addresses, then I'd say that this is a bug in the
X server. There may be similar bugs in other places that get a
list of local addresses.
Seems like a trivial thing for the Xserver to filter out
an IP address of 0.0.0.0 - unless for some bizarre reason
you WANT this address.
The -from option probably could be avoided in most cases, but there are
still some configurations where it would remain useful.
Would one be the case where you have two active
lan
The X server passes xdm a list of addresses, and xdm chooses one
based on its policy. The policy should probably be fixed to favour
the address the request comes from. As it is now, there is no
guarantee that the address it picks is even reachable (which I
think was the real motivation for the -from option).
Ok, so I am not missing something. I can't envision
why you would want to go to other than the machine that
sent out the request.
While this should be corrected, other xdm-derived display managers
probably have the same problem. For your specific problem, the
best immediate solution might be to make sure that the X server
doesn't include unconfigured interfaces in the list of addresses
it passes to xdm.
Other xdm-derived display managers do have the same problem.
dtlogin, from CDE, for example, tries to prevent xdm requests
to the loopback. A proto fix that I made appears to eliminate
attempts to connect to 0.0.0.0. I think it will be useful to
look into what it would take to only connect back the originator.
Is this type of behavior something that you would want options
for? I still can't envision the situation where I would listen
for a request on one interface and then somehow decide to
respond on another.
Thanks,
Rick
--
+--+
| Rick Beldin| Hewlett-Packard Company|
| email: rbeldinATatl.hp.com | Global Solutions Engineering |
|| 20 Perimeter Summit|
|| Atlanta, GA 30319 |
+--+
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
