Re: xfree86 4.0
Subject: xfree86 4.0 Date: Mon, Jun 11, 2001 at 11:59:27PM -0300 In reply to:Eduardo Gargiulo Quoting Eduardo Gargiulo([EMAIL PROTECTED]): Hi all. How can I upgrade my potato_r0 to install xfree86 v4.x? You would have found that question answered if you had look tru the archives. Add this to your sources.list # Debian GNU/Linux 2.2 - XFree86 Version 4.0.3 deb http://people.debian.org/~cpbotha/ xf403_potato/all/ deb http://people.debian.org/~cpbotha/ xf403_potato/i386/ -- User n.: A programmer who will believe anything you tell him. ___
Re: Re: xfree86 4.0
In reply to:Eduardo Gargiulo Quoting Eduardo Gargiulo([EMAIL PROTECTED]): Hi all. How can I upgrade my potato_r0 to install xfree86 v4.x? You would have found that question answered if you had look tru the archives. All these details are 100% in the archives, just look using the keyword xf40. Hmm... and if you wait long enough for the next digest will likely find all my emails outlining what *not* to do for this.. Marc.
Re: XFree86 4.0.x tdfx DRI
Ian Eure wrote: has anyone out there been able to get DRI working properly with XFree86 4.0.x and a 3dfx board? it _seems_ to work, but framerates are low... not at low as with software rendering, but low. i also get horrible flicker when polygons are redrawn. i was told that installing libglide3 would help - it did, but not enough. i still have the same problems. i also tried the debs of cvs dri. it did not help at all. everything worked perfectly with xfree86 3.3.6, mesag3-glide2 and libglide2. my system is a k6-3 500, 192mb ram, with a voodoo3 2000 16mb agp card. With XFree86 3.3.6 i used the 3dfx device, and i remeber quite faster than the actual XFree86 4.0.3 3dfx DRI implementation, correct me if i'm wrong, in the latter case, OpenGL works as an additional software layer, based upon glide-dri... I think i've read somewhere it's still possible to use the 3dfx device with XFree86 4, but can't remember where, so if someone can point me in the right direction... Andrea
Re: XFree86 4.0.x tdfx DRI
has anyone out there been able to get DRI working properly with XFree86 4.0.x and a 3dfx board? it _seems_ to work, but framerates are low... not at low as with software rendering, but low. i also get horrible flicker when polygons are redrawn. i was told that installing libglide3 would help - it did, but not enough. i still have the same problems. i also tried the debs of cvs dri. it did not help at all. everything worked perfectly with xfree86 3.3.6, mesag3-glide2 and libglide2. my system is a k6-3 500, 192mb ram, with a voodoo3 2000 16mb agp card. not on the list, so please cc any replies to me. I've pretty much followed the docs on DRI and X site about setting up the Voodoo3 card. Points of note: 1. You need either the kernel tdfx module, or DRI one. 2. DRI ONLY works in 16bpp, not 24bpp (took me a while to get that one). 3. I use xlibmesa3 and xlibosmesa3 libs. HTH, Andrei -- First there was Explorer... Then came Expedition. This summer Coming to a street near you.. Ford Exterminator. -- Andrei Ivanov http://arshes.dyndns.org [EMAIL PROTECTED] 12402354 --
Re: XFree86 4.0.x tdfx DRI
On Thu, 17 May 2001, Andrei Ivanov wrote: Date: Thu, 17 May 2001 12:05:23 -0500 (CDT) From: Andrei Ivanov [EMAIL PROTECTED] To: Ian Eure [EMAIL PROTECTED] Cc: debian-user@lists.debian.org Subject: Re: XFree86 4.0.x tdfx DRI has anyone out there been able to get DRI working properly with XFree86 4.0.x and a 3dfx board? it _seems_ to work, but framerates are low... not at low as with software rendering, but low. i also get horrible flicker when polygons are redrawn. i was told that installing libglide3 would help - it did, but not enough. i still have the same problems. i also tried the debs of cvs dri. it did not help at all. everything worked perfectly with xfree86 3.3.6, mesag3-glide2 and libglide2. my system is a k6-3 500, 192mb ram, with a voodoo3 2000 16mb agp card. not on the list, so please cc any replies to me. I've pretty much followed the docs on DRI and X site about setting up the Voodoo3 card. Points of note: 1. You need either the kernel tdfx module, or DRI one. 2. DRI ONLY works in 16bpp, not 24bpp (took me a while to get that one). 3. I use xlibmesa3 and xlibosmesa3 libs. irt point 1, i have the agpgart tdfx modules that came with 2.4.4 loaded - afaik the dri stuff is all loaded in the x server, not the kernel. am i wrong on this point? i'm running in 16bpp, and i have xlib[os]mesa3 installed.
Re: XFree86 4.0.x tdfx DRI
irt point 1, i have the agpgart tdfx modules that came with 2.4.4 loaded - afaik the dri stuff is all loaded in the x server, not the kernel. am i wrong on this point? i'm running in 16bpp, and i have xlib[os]mesa3 installed. From what I remember, you can get dri from both kernel source AND dri.sourceforge.net Advantage of kernel being that it's compiled with the kernel together, you can compile it straight into the kernel, and X wont know the difference. Advantage of dri.sourceforge.net being that you get the latest DRI version. But the way it works is that X will have to load dri module when it starts up. But it doesnt matter where it's loaded from: whether it's already in the kernel, or it's in hte X modules, it'll work the same. Andrei -- First there was Explorer... Then came Expedition. This summer Coming to a street near you.. Ford Exterminator. -- Andrei Ivanov http://arshes.dyndns.org [EMAIL PROTECTED] 12402354 --
Re: XFree86-4.0 screen resolution missmatched with monitor viewing area
Quoting John Foster ([EMAIL PROTECTED]): [EMAIL PROTECTED] wrote: The virtual resolution is by default set to the maximum resolution for the display (I think). In the display section add the line: Virtual 1024 768 You might not be able to switch to a larger display, however. See man XF86Config. That did it! It is not exactly what I wanted to achieve, but at least it puts me back to where I was before the upgrade. But isn't this all that's happened (where I've used 1152 864 and a 3.3.6 server): (**) Mach64: Mode 1280x1024: mode clock = 135.000 (--) Mach64: Resolution 1280x1024 too large for virtual 1152x864 (--) Mach64: Removing mode 1280x1024 from list of valid modes. (**) Mach64: Mode 1152x864: mode clock = 110.000 (**) Mach64: Mode 1024x768: mode clock = 85.000 (**) Mach64: Virtual resolution: 1152x864 (--) Mach64: Video RAM: 2048k In other words, you could have merely removed your highest resolution from the list in /etc/X11/XF86Config, making sure of course that the resolution you want to first appear is first in the list. Now if I can just figure out how to coordinate a change in resolution with a corresponding change in virtual screen size. Maybe a virtual display with each resolution. Any ideas? BTW I did see the reference in the docs, but did not understand how they applied. The examples were not clear.:-( A reference to your reference would help. I'm not going to plough through all the X docs on the off chance that I see something that I think might be what you don't understand! Cheers, -- Email: [EMAIL PROTECTED] Tel: +44 1908 653 739 Fax: +44 1908 655 151 Snail: David Wright, Earth Science Dept., Milton Keynes, England, MK7 6AA Disclaimer: These addresses are only for reaching me, and do not signify official stationery. Views expressed here are either my own or plagiarised.
Re: XFree86-4.0 screen resolution missmatched with monitor viewing area
[EMAIL PROTECTED] wrote: The virtual resolution is by default set to the maximum resolution for the display (I think). In the display section add the line: Virtual 1024 768 You might not be able to switch to a larger display, however. See man XF86Config. -Chris -REPLY--- That did it! It is not exactly what I wanted to achieve, but at least it puts me back to where I was before the upgrade. Now if I can just figure out how to coordinate a change in resolution with a corresponding change in virtual screen size. Maybe a virtual display with each resolution. Any ideas? BTW I did see the reference in the docs, but did not understand how they applied. The examples were not clear.:-( -- John Foster
Re: XFree86-4.0 screen resolution missmatched with monitor viewing area
On 8 Feb, John Foster wrote: [EMAIL PROTECTED] wrote: The virtual resolution is by default set to the maximum resolution for the display (I think). In the display section add the line: Virtual 1024 768 You might not be able to switch to a larger display, however. See man XF86Config. -Chris -REPLY--- That did it! It is not exactly what I wanted to achieve, but at least it puts me back to where I was before the upgrade. Now if I can just figure out how to coordinate a change in resolution with a corresponding change in virtual screen size. Maybe a virtual display with each resolution. Any ideas? BTW I did see the reference in the docs, but did not understand how they applied. The examples were not clear.:-( I haven't got been able to do that, either. Anyone else know how to? -Chris | Christopher Judd, Ph. D. | | Research Scientist | | NYS Dept. of Health [EMAIL PROTECTED] | | Wadsworth Center - ESP | | P. O. Box 509518 486-7829 | | Albany, NY 12201-0509 |
Re: XFree86-4.0 screen resolution missmatched with monitor viewing area
Quoth John Foster, I recently upgraded to a full woody/testing installation. After a few hours of reading experimenting with xf86configure I got the new XFree86 4.0 server to work well. I still have 1 problem. The resolutions that are accepted on my monitor are 640x480 800x600 1024x768 1280x1024 24bpp . When the server runs XF86Config-4; it automatically loads the lower resolution first. I then have to manually (CTRL+ALT +/-) change the resolutions. The problem is that when I select While I don't know anything much about X4 modelines, and for myself using the monitor's onscreen display was enough to fix it up, for your problem of starting in the wrong resolution there is an easy fix. Under section `screen', go to the line that represents the colour depth that you're using (which it probably the number next to `DefaultDepth' in that same section. Just put the prefered resolution at the start of the line, and Bob's your uncle. cheers, damon -- Damon Muller | Did a large procession wave their torches Criminologist/Linux Geek | As my head fell in the basket, http://killfilter.com | And was everybody dancing on the casket... PGP (GnuPG): A136E829 | - TBMG, Dead
Re: XFree86-4.0 screen resolution missmatched with monitor viewing area
Damon Muller wrote: While I don't know anything much about X4 modelines, and for myself using the monitor's onscreen display was enough to fix it up, for your problem of starting in the wrong resolution there is an easy fix. Under section `screen', go to the line that represents the colour depth that you're using (which it probably the number next to `DefaultDepth' in that same section. Just put the prefered resolution at the start of the line, and Bob's your uncle. cheers, damon Thanks. I already did that. I'm a perfectionist and prefer to use 1024x768 but the virtual screen is larger than the viewing area by about 40%. In 1280x1024 they match but my eyesight is too poor for that resolution without oversizing everything ...fonts @48, icons @ 120x120. Other ideas? -- John Foster
Re: XFree86-4.0 screen resolution missmatched with monitor viewing area
I think I misunderstood your previous posting where you said In the past I have been able to correct this so I assumed you were trying to do something that was possible in V3. In fact, you didn't correct it, you just lived with it. Thanks. I already did that. I'm a perfectionist and prefer to use 1024x768 but the virtual screen is larger than the viewing area by about 40%. In 1280x1024 they match but my eyesight is too poor for that resolution without oversizing everything ...fonts @48, icons @ 120x120. Other ideas? AFAICT the virtual screen has always been the same size. It slides around so that you can access all points on it. I don't think that has changed between V3 and V4. Viewport just sets the size of the virtual screen, with 0 0 copying the values from the maximum resolution. Have you tried messing with those values (e.g. setting them smaller than max res.); not that I'm saying this works. Cheers, -- Email: [EMAIL PROTECTED] Tel: +44 1908 653 739 Fax: +44 1908 655 151 Snail: David Wright, Earth Science Dept., Milton Keynes, England, MK7 6AA Disclaimer: These addresses are only for reaching me, and do not signify official stationery. Views expressed here are either my own or plagiarised.
Re: XFree86-4.0 screen resolution missmatched with monitor viewing area
On 7 Feb, John Foster wrote: Damon Muller wrote: While I don't know anything much about X4 modelines, and for myself using the monitor's onscreen display was enough to fix it up, for your problem of starting in the wrong resolution there is an easy fix. Under section `screen', go to the line that represents the colour depth that you're using (which it probably the number next to `DefaultDepth' in that same section. Just put the prefered resolution at the start of the line, and Bob's your uncle. cheers, damon Thanks. I already did that. I'm a perfectionist and prefer to use 1024x768 but the virtual screen is larger than the viewing area by about 40%. In 1280x1024 they match but my eyesight is too poor for that resolution without oversizing everything ...fonts @48, icons @ 120x120. Other ideas? The virtual resolution is by default set to the maximum resolution for the display (I think). In the display section add the line: Virtual 1024 768 You might not be able to switch to a larger display, however. See man XF86Config. -Chris | Christopher Judd, Ph. D. | | Research Scientist | | NYS Dept. of Health [EMAIL PROTECTED] | | Wadsworth Center - ESP | | P. O. Box 509518 486-7829 | | Albany, NY 12201-0509 |
Re: XFree86-4.0 screen resolution missmatched with monitor viewing area
Quoting John Foster ([EMAIL PROTECTED]): I recently upgraded to a full woody/testing installation. After a few hours of reading experimenting with xf86configure I got the new XFree86 4.0 server to work well. I still have 1 problem. The resolutions that are accepted on my monitor are 640x480 800x600 1024x768 1280x1024 24bpp . When the server runs XF86Config-4; it automatically loads the lower resolution first. I then have to manually (CTRL+ALT +/-) change the resolutions. The problem is that when I select the one I want...the virtual screen/desktop is diffetent that the actual edge of the monitor. In fact none of these modes match the screen. In the past I have been able to correct this by selecting the startup default with XF86Setup and using only that resolution. That does not seem to work with xf86config or XFree86 -configure xf86cfg completely craps out. I think there is an option called viewport that nees to be set, but the docs do not cover it well enough to try it. Any Suggestions. It would be really cool to be able to switch screen resolutions have them all fit the actual 13.7 viewable area. I have all of the monitor specs and the video card specs as well. I suspect that for most people this is a breeze. I just use the monitor controls to put the picture where I want it for each resolution. The monitor remembers each setting because it's in a different mode (i.e. it recognises the scan frequencies and fishes out the correct settings from an internal table). With old-fashioned monitors that can't do that, I set the controls using my preferred resolution, then switch to the other one (this would be just 800x600 to 640x480) and use xvidtune to scale the new picture. Then I copy the modeline from xvidtune into the XF86Config file at the appropriate place. (Thank goodness I no longer use those old monitors for X). The only problem is: I don't know how XFree86 4 does modelines. It may be different from 3. Cheers, -- Email: [EMAIL PROTECTED] Tel: +44 1908 653 739 Fax: +44 1908 655 151 Snail: David Wright, Earth Science Dept., Milton Keynes, England, MK7 6AA Disclaimer: These addresses are only for reaching me, and do not signify official stationery. Views expressed here are either my own or plagiarised.
Re: XFree86 4.0 and the testing distribution
Xfree86 4.x isn't included in the testing tree yet. The way I understand it, it will be added eventually. I *think* that woody is now the same as the testing tree, but the less stable packages in woody got bumped into the new unstable. People who were running woody before the testing tree came about have X 4, but those of us who just migrated to testing don't. If anyone has a better explanation of this, or sees something wrong with my logic, please chime in, as information about testing seems to be lacking. -Rob On Thu, Dec 21, 2000 at 12:09:35PM -0500, hawk wrote: Gee, the testing distribution was announced later in the day when I decided that a lagged unstable was what was really needed . . . :) Anyway, I've tried toinstall it on the kids machine with mixed success. As near as I can tell, the dependencies between XFree 3.3 and 4.0 cross over. When I select the Xfree tasks, I end up with parts of 3.3 and nothing working. I don't see anything in the archives for the last month or so, so could someone kindly pass me a clue? Thanks hawk, who actually downloaded it all over a 28k modem -- Prof. Richard E. Hawkins, Esq. Smeal 178(814) 375-4700 [EMAIL PROTECTED] These opinions will not be those of Penn State until it pays my retainer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0
On Mon, 27 Nov 2000, Jeffrey A Schoolcraft wrote: * Martin Fluch ([EMAIL PROTECTED]) wrote: apt-get install xserver-xfree86 (this will update not all of your system, but only the part needed by the dependencies) Then fidle around until you get it running, you might need to update some other X related packages. after I did this, I got an error, couldn't load default font 'fixed'. Been looking to see how I can install this font. Any ideas? Perhaps you might look at this mail (and it follow-ups) in the mailinglist archive: http://lists.debian.org/debian-user-0010/msg02761.html Martin PS: This (http://lists.debian.org/debian-user-0010/msg02970.html) seems prommising: Yes, some package that I upgraded forgot to run update-fonts-alias in misc. So, what you need to do as root is: cd /usr/X11R6/lib/X11/fonts update-fonts-alias misc -- This is Linux Country. In a quiet night, you can hear Windows reboot. For public GnuPG-key: finger [EMAIL PROTECTED]
Re: XFree86 4.0
hi martin, if i don't upgrade to woody, would it be better to do this from source packages? i'm wondering if X will be linked against woody libraries... thanks! pete linux To err is human, to forgive is divine. [EMAIL PROTECTED] _ To oink is porcine, to meow is feline.http://www.dirac.org/p._. To neigh is equine to howl is lupine, /v\ To moo is bovine to bleat is ovine.// \\ ^^ ^^ The best way to accelerate a win95 system is at 9.81 m/s^2 rules On Tue, 28 Nov 2000, Martin Fluch wrote: Date: Tue, 28 Nov 2000 01:20:00 +0200 (EET) From: Martin Fluch [EMAIL PROTECTED] To: Peter Jay Salzman [EMAIL PROTECTED] Cc: Debian user mailing list debian-user@lists.debian.org Subject: Re: XFree86 4.0 Hi! I think you want to stick to the package system. If you use apt-get, change the /etc/apt/sources.list so that it points to unstable, then make an apt-get update then a apt-get install xserver-xfree86 (this will update not all of your system, but only the part needed by the dependencies) Then fidle around until you get it running, you might need to update some other X related packages. Afterwards restor the old sources.list and make an apt-get update again to get the old package informations back. This should be easier than tarballs... Martin On Mon, 27 Nov 2000, Peter Jay Salzman wrote: I'd like to upgrade to XFree86 4.0. The way I see it, there's 2 options: 1- package 2- tarball I'm running Potato, and don't really want to upgrade to Woody. Based on that alone, I think tarball is my only option, but I want to make sure of that. Which is the better way for me to upgrade X? -- This is Linux Country. In a quiet night, you can hear Windows reboot.
Re: XFree86 4.0
On Tue, 28 Nov 2000, Peter Jay Salzman wrote: if i don't upgrade to woody, would it be better to do this from source packages? i'm wondering if X will be linked against woody libraries... In my opinion it should be much more less truble to upgrade only some packages to woody. Then at least the package management system knows about what is going on, and the xserver packages would be better integrated into the whole Debian system. A friend of mine has a potato box which has some unstable packages installed (it would take about 140MB download to upgrade it completely to to a most recent woody system), and it worked well. Recently it happende to him, that while he installed the woody version of gnucash, that also the xserver was updated. This caused some minor breakage, but after updating some more packages (mostly some X packages which weren't automaticaly updated by apt-get automaticaly, and the sawfish package) and fixing some bugs manualy (something like to change the DisplayManager.randomFile in /etc/X11/xdm/xdm-config from /dev/urandom to /dev/mem, or to correct a symbolic link here ... so no real _big_ bugs) the whole system worked well and stable again, no further problems. I guess to fix these small things is much less trouble then compiling and installing XFree from tarbals and get it then smothly running. Branden did in my opinion a very, very well job, and apt-get/dpkg does its own job also _very_ well... Martin -- This is Linux Country. In a quiet night, you can hear Windows reboot. For public GnuPG-key: finger [EMAIL PROTECTED]
Re: XFree86 4.0
Hi! I think you want to stick to the package system. If you use apt-get, change the /etc/apt/sources.list so that it points to unstable, then make an apt-get update then a apt-get install xserver-xfree86 (this will update not all of your system, but only the part needed by the dependencies) Then fidle around until you get it running, you might need to update some other X related packages. Afterwards restor the old sources.list and make an apt-get update again to get the old package informations back. This should be easier than tarballs... Martin On Mon, 27 Nov 2000, Peter Jay Salzman wrote: I'd like to upgrade to XFree86 4.0. The way I see it, there's 2 options: 1- package 2- tarball I'm running Potato, and don't really want to upgrade to Woody. Based on that alone, I think tarball is my only option, but I want to make sure of that. Which is the better way for me to upgrade X? -- This is Linux Country. In a quiet night, you can hear Windows reboot. For public GnuPG-key: finger [EMAIL PROTECTED]
Re: XFree86 4.0
* Martin Fluch ([EMAIL PROTECTED]) wrote: apt-get install xserver-xfree86 (this will update not all of your system, but only the part needed by the dependencies) Then fidle around until you get it running, you might need to update some other X related packages. after I did this, I got an error, couldn't load default font 'fixed'. Been looking to see how I can install this font. Any ideas?
Re: XFree86 4.0 debs ?
Ron Rademaker [EMAIL PROTECTED] writes: PS. Make sure to keep the old 3, just in case anything goes wrong, I didn't the first time, something went wrong, so I tried to fix it and messed up my system even more. At the end I decided to reinstall the system, because it was the fastest way of fixing ;) In file xc/config/cf/site.def, change ProjectRoot, for example: #define ProjectRoot /usr/local/X11R6 Remove comments around #ifndef HasGcc2 #define HasGcc2 YES #endif Then just make world; make install. XF86Config should be changed, /etc/X11/Xserver edited, and that's it. You don't have to remove any debian packages. -- M. Tavasti / [EMAIL PROTECTED] / +358-40-5078254 Poista sähköpostiosoitteesta molemmat x-kirjaimet Remove x-letters from my e-mail address
Re: XFree86 4.0 debs ?
There aren't any deb (yet), but you can compile the sources yourself, works fine here! Ron Rademaker PS. Make sure to keep the old 3, just in case anything goes wrong, I didn't the first time, something went wrong, so I tried to fix it and messed up my system even more. At the end I decided to reinstall the system, because it was the fastest way of fixing ;) On Tue, 23 May 2000, James Sleeman wrote: I would like to install XFree 4.0 on my potato machine, are there debs available yet, or not too far off ? I couldn't even see 4.0 ones in Woody. Thanks James Sleeman -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
gs, wmaker debs? (was: Re: XFree86 4.0 debs ?)
On Tue, 23 May 2000, James Sleeman [EMAIL PROTECTED] wrote: I would like to install XFree 4.0 on my potato machine, are there debs available yet, or not too far off ? I couldn't even see 4.0 ones in Woody. Take a look at http://www.debian.org/~branden/plans.txt. It seems like the move to the new architecture is non-trivial (haven't tried it myself). A similar question: I've been looking for debs of gs 6.0 and wmaker 0.62. Both are out for quite some time now, but they're not even in woody. Is this because all maintainers are busy getting potato out? I've built wmaker and libproplist myself and it works right out of the box on potato. Merely a matter of half an hour (not flaming or anything, I'm just curious). -- Philip Lehman [EMAIL PROTECTED]
Re: XFree86 4.0 deb
They don't exist yet. Michael O'Brien wrote: Hola~ Anyone know of the location of an xfree86 4.0 deb file? MO -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: XFree86 4.0 and Xterm colors...
On Sun, Apr 30, 2000 at 06:02:07PM -0700, Eric G . Miller wrote: I've installed, and managed to get working, XFree86 4.0. The only big problem remaining is that all of the terminal colors are really weird. I now get pink on magenta and other generally unreadable color combinations when I run mutt, slrn, etc. I've been trying to figure out where these colors got messed up, and I guessed it was in the new terminfo entries. Unfortunately, I don't know which ones are mucked up or how to change them. Any pointer's would be handy. Thanks. -- I've gotten around this temporarily by using gnome-terminal instead. -- ¶ One·should·only·use·the·ASCII·characterset·when·compos » ing·email·messages.
Re: XFree86-4.0 and xauth
On Mon, Apr 24, 2000 at 07:10:59PM -0400, Brian Stults wrote:
I upgraded to XFree86-4.0 recently, and now xauth doesn't seem to work.
i don't use XFree86-4.0 yet, but here's guess or two.
I usually use ssh to work on my unix account at work and to do so, I
have a script that looks like this:
ssh REMOTEHOST /usr/openwin/bin/xauth add `grep -e IPADDR
/etc/dhcpc/dhcpcd-eth0.info | gawk -F = '{print $2}'`:0 . `xauth list
LOCALHOST/unix:0 | gawk '{print $3}'`
Have you checked that this still generates the right output? i.e. what
is is supposed to generate and what does it actually do? Change the
cookie if you want to post it, no one will know the difference.
For example, in my xauth file i have keys for both MIT-MAGIC-COOKIE-1
and XDM-AUTHORIZATION-1. If the XDM-AUTHORIZATION-1 would have happened
to come first, it would be using the wrong cookie for your script.
xterm -e ssh REMOTEHOST
This basically gets my current IP address from the dhcpcd info, and uses
ssh to add the xauth code for that IP to my list on the remote host.
Just out of curiousity, why don't you just use ssh's X forwarding?
Especially since the long-standing bug that made it fail on some
configurations has been fixed in the latest Debian versions.
However, since I upgraded to 4.0, this doesn't work. Even if I do it
manually on the remote host, it still doesn't work. When I try to
execute a program on the remote host with the display exported to my
localhost, I get this:
Xlib: connection to LOCALHOST:0.0 refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
xterm Xt error: Can't open display: LOCALHOST:0
When you say 'manually' do you mean manually ran the script or did
xauth list and copy-pasted the output by hand into the remote session?
Apparently, there's some issue with the key being different... The only
guess i have at the moment is that that script is producing incorrect
output.
--
finger for GPG public key.
pgpRLF1pv475n.pgp
Description: PGP signature
