Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
Luca Olivetti wrote: Giuseppe Ghibò wrote: mplayer plays just fine *and* uses xv, I was reporting the message for completeness. Bye mplayer 0.90rc4 can player remotely too (use -vo x11 if -vo xv is not working remotely in that case). $ rpm -q mplayer mplayer-0.90-0.rc4.4plf anyway the original question was if glx/xv work remotely, I just used mplayer to test remote xv :-) glx 3D acceleration doesn't work remotely, or to be honest what is not work remotely is DRI. To get glx working remotely you need Indirect Rendering, available for instance on old Utah GLX (works only on XF 3.3.6), which allows to obtain 3D acceleration even remotely. Maybe some other glx library not using DRI could offer that too. Bye. Giuseppe.
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
On Wednesday 05 March 2003 08:02 pm, Giuseppe Ghibò wrote: glx 3D acceleration doesn't work remotely, or to be honest what is not work remotely is DRI. To get glx working remotely you need Indirect Rendering, available for instance on old Utah GLX (works only on XF 3.3.6), which allows to obtain 3D acceleration even remotely. Maybe some other glx library not using DRI could offer that too. Ideally, use DRI if avbailable, avoid it and still do 3D if not. Cheers; Leon
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
sounds like your looking for something similar to Xmove. jeremy Leon Brooks wrote: On Monday 03 March 2003 10:37 pm, Danny Tholen wrote: Loki's Kohan runs only in 1024x768, but I hate using my desktop in that resolution (low refresh, small fonts). Switching during session would be nice. And certainly easier compared to starting a new xserver. Hmm... some of you will probably rate this offtopic, but if you don't drop seeds you'll never get trees... Sun have this really cool feature for their SunRay and similar workstations which allows you to log in to any random terminal with a card; when you pull out your card your session is either suspended or shovelled into /dev/null; when you plug in elsewhere it comes back up again. To do this, the apps must be able to cope with different kinds of screens (resolution and colour depth at least) and changing those on the fly. But as you've exemplified here, not all apps will co-operate. One possible solution is to use XNest, and run the offending app in a `screen size' that it likes, but XNest (even a `rootless XNest!') isn't quite what I have in mind. Xv also provides a useful facility, a not-quite-bitbucket X server, but this is also not what I'm seeking. Think `screen' for X. What I want is an interface layer which sits between the apps and the real X server (or perhaps between the WM and the real server would be better), and in normal circumstances does nothing, uses little or no resources (e.g., calls are vectored straight through to the real server untouched). If you pulled the card from your screen, logged out, or whatever (maybe the ssh tunnel fails), the interface layer would take charge and either SIGSTOP the processes attached through it, route the outbound traffic to /dev/null and fake the inbound traffic, route the traffic to an Xv-like or some combination of the above. When you plugged in again, logged in again, rebuilt your VPN or whatever, you would be able to attach (even at a different screen rez or depth) your existing session and do a refresh. Apps which didn't indicate an ability to handle an environment different to the one they started in would be emulated (e.g. scaled to fit on a smaller or larger screen, run through an XNest-like emulator for differing screen depths. I'm not sure that this would work at all well for OpenGL apps, but OTOH they should in theory be able cope with scaling issues (a change in the surface they're rendering to) much more seamlessly than an app which knows so much more about X directly. The ability to invoke virtual magic on a per-app basis would be very nice (e.g. scale Tower Topler window contents 2x2 or 3x3 on this 2000x1600 screen so I can actually see what's happening, crush down the huge linuxconf intro panel so I can see it all on an 800x600 screen). RandR-type resizing/redepthing would be handled in pretty much the same way as a detach/reattach-at-different-rez. You could `broadcast' an X app or screen with this technology to a bunch of disparate machines for teaching or meeting-style apps, and have most of the depth/size and similar tradeoffs handled the same way that they would be for any other app appearing on each server's desktop. Fitting 2D apps into a proper 3D desktop would be relatively trivial with this technology, you'd just `reattach' the app to an OpenGL surface. Now... is there anything around which does all/most of this already? Any of the 3D WM's, for example, that virtualise a lot of stuff without much of a performance hit? Cheers; Leon
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
On Tuesday 04 March 2003 06:24, Leon Brooks wrote: On Monday 03 March 2003 10:37 pm, Danny Tholen wrote: Loki's Kohan runs only in 1024x768, but I hate using my desktop in that resolution (low refresh, small fonts). Switching during session would be nice. And certainly easier compared to starting a new xserver. Hmm... some of you will probably rate this offtopic, but if you don't drop seeds you'll never get trees... Sun have this really cool feature for their SunRay and similar workstations which allows you to log in to any random terminal with a card; when you pull out your card your session is either suspended or shovelled into /dev/null; when you plug in elsewhere it comes back up again. snip--- Now... is there anything around which does all/most of this already? Any of the 3D WM's, for example, that virtualise a lot of stuff without much of a performance hit? Cheers; Leon I don't know if there is anything like this. But for sure it is not possible to use things like xv or OpenGL on remote workstations. For this you have to sit on the very same machine. But taken two steps lower is interesting enough. Didn't the gdm provides this fast user switching ? Could this be triggered by a card-reader and the right card. At least it seems interesting enough to keep this in mind for 9.2 doesn't it ? Another idea for authentification would be an usb-memory-stick. -- Regards Steffen counter.li.org : #296567. machine: 181800 vdr-box : 87 Please dont CC me, since if I have replied I'll watch the tread. Both mails will be filtered to the ML-folder. Thanks
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
Am Dienstag, 4. März 2003, 11:36:14 Uhr MET, schrieb Steffen Barszus: I don't know if there is anything like this. But for sure it is not possible to use things like xv or OpenGL on remote workstations. For this you have to sit on the very same machine. Who said that? glx can use a remote display, I'm not sure about xv, but I guess that's similar. But taken two steps lower is interesting enough. Didn't the gdm provides this fast user switching ? Could this be triggered by a card-reader and the right card. At least it seems interesting enough to keep this in mind for 9.2 doesn't it ? Another idea for authentification would be an usb-memory-stick. Sure, that would be a nice idea. Are those smard card readers supported by Linux? I see those Fujitsu Siemens boxes with card readers everywhere. -- Götz Waschk master of computer science University of Rostock http://wwwtec.informatik.uni-rostock.de/~waschk/waschk.asc for PGP key -- Logout Fascism! --
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
On Tuesday 04 March 2003 11:40, Götz Waschk wrote: Am Dienstag, 4. März 2003, 11:36:14 Uhr MET, schrieb Steffen Barszus: I don't know if there is anything like this. But for sure it is not possible to use things like xv or OpenGL on remote workstations. For this you have to sit on the very same machine. Who said that? glx can use a remote display, I'm not sure about xv, but I guess that's similar. Hmm I thought at least xv uses a similar approach as the dri and dri bypasses the normal Xserver for direct access to the hardware, I thought for GL it is the same. But I can be wrong. But taken two steps lower is interesting enough. Didn't the gdm provides this fast user switching ? Could this be triggered by a card-reader and the right card. At least it seems interesting enough to keep this in mind for 9.2 doesn't it ? Another idea for authentification would be an usb-memory-stick. Sure, that would be a nice idea. Are those smard card readers supported by Linux? I see those Fujitsu Siemens boxes with card readers everywhere. The easiest approach is the usb-memory-stick ;) (f.i. a second small partition with the key on it) But there are some card-readers that are supported under linux. I have done some investigation for HBCI-banking: - towitoko-card-reader - Reiner SCT (the USB Class 3 card-reader, can't remember the name, but reiner sct provides driver for it) == my favourite, but can't afford it currently. There may be more supported and i can search a but in old c't-magazins (or was it Linux Magazin ?) since there was an article about card-readers under linux, which are supported and how to enable them and how to write a programm to use it. In the club is also a discussion about GnuCash and OpenHBCI that may be a bit related (homebanking). I guess we would need an cardreader-enabled gdm or kdm for it, but i can't present fact currently ;) -- Regards Steffen counter.li.org : #296567. machine: 181800 vdr-box : 87 Please dont CC me, since if I have replied I'll watch the tread. Both mails will be filtered to the ML-folder. Thanks
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
On Tue, 2003-03-04 at 02:40, Götz Waschk wrote: Am Dienstag, 4. März 2003, 11:36:14 Uhr MET, schrieb Steffen Barszus: I don't know if there is anything like this. But for sure it is not possible to use things like xv or OpenGL on remote workstations. For this you have to sit on the very same machine. Who said that? glx can use a remote display, I'm not sure about xv, but I guess that's similar. is that new? Didn't work in 4.2... -- Jack Coates Monkeynoodle: A Scientific Venture...
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
Götz Waschk wrote: Who said that? glx can use a remote display, I'm not sure about xv, but I guess that's similar. I don't know about glx, but I tried playing a movie with mplayer on an ltsp terminal and it is using xv, the message is Shared memory not available, reverting to normal Xv. The real issue is sound, it is difficult to get all applications working in a consistent way, thankfully mplayer has a nas audio plugin. Bye -- Luca Olivetti Note.- This message reached you today, it may not tomorrow if you are using MAPS or other RBL. They arbitrarily IP addresses not related in any way to spam, disrupting Internet connectivity. See http://slashdot.org/article.pl?sid=01/05/21/1944247 and http://theory.whirlycott.com/~phil/antispam/rbl-bad/rbl-bad.html pgp0.pgp Description: PGP signature
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
Am Dienstag, 4. März 2003, 17:56:35 Uhr MET, schrieb Luca Olivetti: I don't know about glx, but I tried playing a movie with mplayer on an ltsp terminal and it is using xv, the message is Shared memory not available, reverting to normal Xv. The real issue is sound, it is difficult to get all applications working in a consistent way, thankfully mplayer has a nas audio plugin. That's true, MPlayer defaults to XShm if you compile it on a machine with xshm support. Try xine, it can play to a remote X display. -- Götz Waschk master of computer science University of Rostock http://wwwtec.informatik.uni-rostock.de/~waschk/waschk.asc for PGP key -- Logout Fascism! --
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
Götz Waschk wrote: Am Dienstag, 4. März 2003, 17:56:35 Uhr MET, schrieb Luca Olivetti: I don't know about glx, but I tried playing a movie with mplayer on an ltsp terminal and it is using xv, the message is Shared memory not available, reverting to normal Xv. The real issue is sound, it is difficult to get all applications working in a consistent way, thankfully mplayer has a nas audio plugin. That's true, MPlayer defaults to XShm if you compile it on a machine with xshm support. Try xine, it can play to a remote X display. mplayer plays just fine *and* uses xv, I was reporting the message for completeness. Bye -- Luca Olivetti Note.- This message reached you today, it may not tomorrow if you are using MAPS or other RBL. They arbitrarily IP addresses not related in any way to spam, disrupting Internet connectivity. See http://slashdot.org/article.pl?sid=01/05/21/1944247 and http://theory.whirlycott.com/~phil/antispam/rbl-bad/rbl-bad.html pgp0.pgp Description: PGP signature
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
Luca Olivetti wrote: Götz Waschk wrote: Am Dienstag, 4. März 2003, 17:56:35 Uhr MET, schrieb Luca Olivetti: I don't know about glx, but I tried playing a movie with mplayer on an ltsp terminal and it is using xv, the message is Shared memory not available, reverting to normal Xv. The real issue is sound, it is difficult to get all applications working in a consistent way, thankfully mplayer has a nas audio plugin. That's true, MPlayer defaults to XShm if you compile it on a machine with xshm support. Try xine, it can play to a remote X display. mplayer plays just fine *and* uses xv, I was reporting the message for completeness. Bye mplayer 0.90rc4 can player remotely too (use -vo x11 if -vo xv is not working remotely in that case). Bye. Giuseppe.
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
Giuseppe Ghibò wrote: mplayer plays just fine *and* uses xv, I was reporting the message for completeness. Bye mplayer 0.90rc4 can player remotely too (use -vo x11 if -vo xv is not working remotely in that case). $ rpm -q mplayer mplayer-0.90-0.rc4.4plf anyway the original question was if glx/xv work remotely, I just used mplayer to test remote xv :-) Bye -- Luca Olivetti Note.- This message reached you today, it may not tomorrow if you are using MAPS or other RBL. They arbitrarily IP addresses not related in any way to spam, disrupting Internet connectivity. See http://slashdot.org/article.pl?sid=01/05/21/1944247 and http://theory.whirlycott.com/~phil/antispam/rbl-bad/rbl-bad.html pgp0.pgp Description: PGP signature
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
On Wednesday 05 March 2003 00:10, Luca Olivetti wrote: Giuseppe Ghibò wrote: mplayer plays just fine *and* uses xv, I was reporting the message for completeness. Bye mplayer 0.90rc4 can player remotely too (use -vo x11 if -vo xv is not working remotely in that case). $ rpm -q mplayer mplayer-0.90-0.rc4.4plf anyway the original question was if glx/xv work remotely, I just used mplayer to test remote xv :-) Bye Has anyone a site up to save such ideas, there further research results and infos can be saved ? (the original idea of this thread) -- Regards Steffen counter.li.org : #296567. machine: 181800 vdr-box : 87 Please dont CC me, since if I have replied I'll watch the tread. Both mails will be filtered to the ML-folder. Thanks
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
On Tuesday 04 March 2003 06:36 pm, Steffen Barszus wrote: Didn't the gdm provides this fast user switching ? No. GDM left a user running on one display, and opened a new display (same card) for the new user. Cheers; Leon
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
On Tuesday 04 March 2003 07:47 pm, Steffen Barszus wrote: On Tuesday 04 March 2003 11:40, Götz Waschk wrote: Am Dienstag, 4. März 2003, 11:36:14 Uhr MET, schrieb Steffen Barszus: I don't know if there is anything like this. But for sure it is not possible to use things like xv or OpenGL on remote workstations. For this you have to sit on the very same machine. Who said that? glx can use a remote display, I'm not sure about xv, but I guess that's similar. Hmm I thought at least xv uses a similar approach as the dri and dri bypasses the normal Xserver for direct access to the hardware, I thought for GL it is the same. But I can be wrong. Yes, OpenGL != DRI. DRI is a *technique* often used for implementing OpenGL, but which IIRC sacrifices the networkness. The easiest approach is the usb-memory-stick ;) Agree. Some Oz schools use that. Cheaper and more widely available, and can store bucketloads of stuff compared with many cards. If need be, could put a microdrive in one for several gigabytes of storage, but that would cost you some robustness. Cheers; Leon
Re: [Cooker] XFuture (was: Xfree 4.3 and RandR)
On Monday 03 March 2003 10:37 pm, Danny Tholen wrote: Loki's Kohan runs only in 1024x768, but I hate using my desktop in that resolution (low refresh, small fonts). Switching during session would be nice. And certainly easier compared to starting a new xserver. Hmm... some of you will probably rate this offtopic, but if you don't drop seeds you'll never get trees... Sun have this really cool feature for their SunRay and similar workstations which allows you to log in to any random terminal with a card; when you pull out your card your session is either suspended or shovelled into /dev/null; when you plug in elsewhere it comes back up again. To do this, the apps must be able to cope with different kinds of screens (resolution and colour depth at least) and changing those on the fly. But as you've exemplified here, not all apps will co-operate. One possible solution is to use XNest, and run the offending app in a `screen size' that it likes, but XNest (even a `rootless XNest!') isn't quite what I have in mind. Xv also provides a useful facility, a not-quite-bitbucket X server, but this is also not what I'm seeking. Think `screen' for X. What I want is an interface layer which sits between the apps and the real X server (or perhaps between the WM and the real server would be better), and in normal circumstances does nothing, uses little or no resources (e.g., calls are vectored straight through to the real server untouched). If you pulled the card from your screen, logged out, or whatever (maybe the ssh tunnel fails), the interface layer would take charge and either SIGSTOP the processes attached through it, route the outbound traffic to /dev/null and fake the inbound traffic, route the traffic to an Xv-like or some combination of the above. When you plugged in again, logged in again, rebuilt your VPN or whatever, you would be able to attach (even at a different screen rez or depth) your existing session and do a refresh. Apps which didn't indicate an ability to handle an environment different to the one they started in would be emulated (e.g. scaled to fit on a smaller or larger screen, run through an XNest-like emulator for differing screen depths. I'm not sure that this would work at all well for OpenGL apps, but OTOH they should in theory be able cope with scaling issues (a change in the surface they're rendering to) much more seamlessly than an app which knows so much more about X directly. The ability to invoke virtual magic on a per-app basis would be very nice (e.g. scale Tower Topler window contents 2x2 or 3x3 on this 2000x1600 screen so I can actually see what's happening, crush down the huge linuxconf intro panel so I can see it all on an 800x600 screen). RandR-type resizing/redepthing would be handled in pretty much the same way as a detach/reattach-at-different-rez. You could `broadcast' an X app or screen with this technology to a bunch of disparate machines for teaching or meeting-style apps, and have most of the depth/size and similar tradeoffs handled the same way that they would be for any other app appearing on each server's desktop. Fitting 2D apps into a proper 3D desktop would be relatively trivial with this technology, you'd just `reattach' the app to an OpenGL surface. Now... is there anything around which does all/most of this already? Any of the 3D WM's, for example, that virtualise a lot of stuff without much of a performance hit? Cheers; Leon
