Re: Prepackaged indirected X terminal
Thanks, Karl, that is much neater than the way I was doing it. What I'm trying to set up is this ... The nameservers are all running xdm to catch broadcast xdmcp requests. These are given the chooser with a list of host names that is automatically derived from the nameserver content. Each calling server is thus indirected to the desired computer; in many cases, this will be the localhost just like the default. Why ? I'd like to set this up because we have computers sitting around, most of which are connected to a variety of experimental systems. If two people want to work on the same system, or if the area around that system is not conducive to placing a human nearby, people simply grab the console of a nearby computer and work normally. It gets irritating fast, having to deal with a display manager that starts applications locally when you really want to run the apps on the target system. Starting the X server from inittab with the -indirect option implements this very nicely, but it is a pain switching each machine over by editing Xservers and inittab, putting in the tweaks that would normally live in Xreset (for a given server) and making sure the command line options in inittab match up with the values that were being used in xdm ... so it works! Thus, I was wondering whether there was a clean way to have xdm start (and restart) the X on the local computer, and send the display off for an xdmcp indirect where it would normally use the xlogin interface immediately.
Re: Prepackaged indirected X terminal
Thanks, Karl, that is much neater than the way I was doing it. What I'm trying to set up is this ... The nameservers are all running xdm to catch broadcast xdmcp requests. These are given the chooser with a list of host names that is automatically derived from the nameserver content. Each calling server is thus indirected to the desired computer; in many cases, this will be the localhost just like the default. Why ? I'd like to set this up because we have computers sitting around, most of which are connected to a variety of experimental systems. If two people want to work on the same system, or if the area around that system is not conducive to placing a human nearby, people simply grab the console of a nearby computer and work normally. It gets irritating fast, having to deal with a display manager that starts applications locally when you really want to run the apps on the target system. Starting the X server from inittab with the -indirect option implements this very nicely, but it is a pain switching each machine over by editing Xservers and inittab, putting in the tweaks that would normally live in Xreset (for a given server) and making sure the command line options in inittab match up with the values that were being used in xdm ... so it works! Thus, I was wondering whether there was a clean way to have xdm start (and restart) the X on the local computer, and send the display off for an xdmcp indirect where it would normally use the xlogin interface immediately. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Prepackaged indirected X terminal
From: Karl Hammar <[EMAIL PROTECTED]> > $ man Xserver | sed -n -e '288,340p' Yes, I know. From: Alexander Perry <[EMAIL PROTECTED]> > [...] > I can do it by disabling it in xdm and putting a line in the > inittab, but the authentication stuff is a pain and I'm > assuming there must be a better way of setting it all up. xdm (for example) supports - local: the server is local and the management is local - foreign: the server is remote and we need to kick it - xdmcp: the server is remote and it will come to us I was wondering whether there was a way to request - remote: the server is local and management is remote I'd like xdm to deal with monitoring and restarting the server, yet not try to take control of that display. Alex.
Re: Prepackaged indirected X terminal
From: Karl Hammar <[EMAIL PROTECTED]> > $ man Xserver | sed -n -e '288,340p' Yes, I know. From: Alexander Perry <[EMAIL PROTECTED]> > [...] > I can do it by disabling it in xdm and putting a line in the > inittab, but the authentication stuff is a pain and I'm > assuming there must be a better way of setting it all up. xdm (for example) supports - local: the server is local and the management is local - foreign: the server is remote and we need to kick it - xdmcp: the server is remote and it will come to us I was wondering whether there was a way to request - remote: the server is local and management is remote I'd like xdm to deal with monitoring and restarting the server, yet not try to take control of that display. Alex. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Prepackaged indirected X terminal
I know how to have xdm use the indirect and chooser features to work with external X terminals and determine where they go. Works great, but it leaves me with a simple question ... Is there a clean way to specify that the locally managed display should be indirected (like a terminal would be) for the option of attaching it elsewhere instead of locally ? I can do it by disabling it in xdm and putting a line in the inittab, but the authentication stuff is a pain and I'm assuming there must be a better way of setting it all up. Separately to that, the X traffic of a remoted display is not normally encrypted. Sometimes that is important. Is there a clean way to have that local X display make its connection to the remote machine using (for example) ssh -X ? I know how to do it manually, with some extra scripting, but I was hoping that there was something packaged for this. Alex.
Prepackaged indirected X terminal
I know how to have xdm use the indirect and chooser features to work with external X terminals and determine where they go. Works great, but it leaves me with a simple question ... Is there a clean way to specify that the locally managed display should be indirected (like a terminal would be) for the option of attaching it elsewhere instead of locally ? I can do it by disabling it in xdm and putting a line in the inittab, but the authentication stuff is a pain and I'm assuming there must be a better way of setting it all up. Separately to that, the X traffic of a remoted display is not normally encrypted. Sometimes that is important. Is there a clean way to have that local X display make its connection to the remote machine using (for example) ssh -X ? I know how to do it manually, with some extra scripting, but I was hoping that there was something packaged for this. Alex. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Can I just yank GLU out of Mesa ?
Much to my amazement, the XF401 phase 1 installed nicely (after using the --force-depends) on a new potato machine. Unfortunately, I haven't managed to take advantage of the DRI because most of the Mesa demos (and plib1) rely on having GLU available. Is there anything 'different' about the xlibgl1 contents that would preclude running happily, if I simply recompile mesa to just create GLU ? Not that I'm impatient ... I'd just rather not wait! It seems wrong to run software mesa on a GeForce... Grin.
Can I just yank GLU out of Mesa ?
Much to my amazement, the XF401 phase 1 installed nicely (after using the --force-depends) on a new potato machine. Unfortunately, I haven't managed to take advantage of the DRI because most of the Mesa demos (and plib1) rely on having GLU available. Is there anything 'different' about the xlibgl1 contents that would preclude running happily, if I simply recompile mesa to just create GLU ? Not that I'm impatient ... I'd just rather not wait! It seems wrong to run software mesa on a GeForce... Grin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
