Re: [Xpert]Re: SuperProbe
"Mike A. Harris" wrote: > > > On Sat, 16 Feb 2002, Ben Craft wrote: > > >Date: Sat, 16 Feb 2002 14:45:38 -0500 > >From: Ben Craft <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Content-Type: text/plain; charset=iso-8859-1 > >List-Id: General X Discussion > >Subject: SuperProbe > > > >Where is the current version of SuperProbe? > > SuperProbe no longer exists. It was deprecated, and removed from > XFree86 sources as of 4.2.0. Replaced largely with XFree86's ability to do probing, via: X -probeonly -- Kevin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]multimedia keycode mismatches under USB versus PS/2
I'm using XFree86 4.1.0 on a self-built Linux 2.4.17 kernel. I have a
Microsoft Natural Keyboard Pro; this keyboard has both PS/2 and USB
connectors. The keyboard's extra row of multimedia and Internet keys
work great using PS/2 and the "microsoftpro" XkbModel. If I switch to
USB, though, something misbehaves. As reported by the X server,
several keys' keycodes change and no longer match up with the proper
keysyms. For example, the "My Computer" key yields keycode 235 when
using PS/2, but keycode 111 when using USB.
(Coincidentally, keycode 111 also happens to be the keycode generated by
the "PrintScn" key. That means that there's no combination of xmodmap
magic that can fix this. Once the two keys have the same keycode, it's
beyond fixing.)
I realize that a lot happens between the USB drivers and the X server.
Is what I'm seeing a USB driver bug? A more generic Linux kernel input
layer bug? An X server bug?
I understand that my keyboard appears as two USB interfaces: one for
the standard keys and one for these extra keys. So at some layer in
the system these are being merged into one stream. Who does that? At
what point do two distinct keys ("My Computer" and "PrintScn") from
two distinct key devices map into a single numeric code (111)? If
that's happening in the X server, then perhaps this is an X server
bug. If that multiplexing is happening below the X server, then it
seems the bug must be down in the Linux kernel or USB drivers.
Suggestions are welcomed, as are polite instructions to report this
elsewhere if it genuinely is someone else's bug. I have already
reported this to the mailing list, but my inquiry
was met with complete and utter silence. :-(
Attached below is a comparison chart showing, for each key, the code
reported by the X server when using PS/2 and USB. (I don't know if
that's useful, but like I said, I'm not sure which software layer is
responsible for this bug.)
Thank you!
Label PS/2USB
- ---
Back234 234
Forward 233 233
Stop232 232
Refresh 231 121 (mismatch)
Search 229 229
Favorites 230 230
Web/Home178 130 (mismatch)
Mail236 236
Mute160 166 (mismatch)
- (volume) 174 165 (mismatch)
+ (volume) 176 158 (mismatch)
Play/Pause 162 159 (mismatch)
Stop164 151 (mismatch)
Prev Track 144 164 (mismatch)
Next Track 153 162 (mismatch)
Media 237 129 (mismatch)
My Computer 235 111 (mismatch)
Calculator 161 161
Sleep 223 227 (mismatch)
Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
> This will result in no available text consoles, but you can still use > Crtl-Alt-Fn to switch to a blank, unused VT. He doesn't want that to be > available. Hmmm, OK. Then there is a need for this functionality. BTW, this isn't way it works on FreeBSD with syscons, possibly other *BSDs as well. If I run getty's on vty[0-3] & X11 on vty8, I can't switch to the "unused" VTY's, it just beeps. > I think all that is needed is a simple utility to lock the VT. > The same code would be used in XFree86, but it doesn't need to be > in XFree86 to work: > > ioctl (fd, VT_LOCKSWITCH, 1); /* lock the switch */ > ioctl (fd, VT_UNLOCKSWITCH, 1); /* unlock it again */ Hmm, and how many systems will recognise those ioctls again? The original user was after a solution for Linux but I'm not interested in providing a Linux-specific solution as I'd prefer to address the generic case for all OSes that have VTY-switching support. Then it might actually be useful to me as well one day. Cheers, AS msg04210/pgp0.pgp Description: PGP signature
Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
To lock VT switching, try the following simple code.
This is nice because root can re-enable switching to
get a terminal if needed.
Compile the code below.
Run it in the first console with: vtlock lock /dev/tty
Next, enter startx -- vt1
You now have X on vt1, non-switchable.
For X on the usual vt7, lock it with: vtlock lock /dev/tty7
/* vtlock.c -- A simple virtual termnial [un]locker */
#include
#include
#include
int main(int argc, char *argv[]){
int fd,lock;
if (argc<2){
fprintf(stderr,"Usage: %s lock|unlock \n"
"\tlock or unlock the given tty.\n",
argv[0]);
exit(-1);
}
if (!(fd=open(argv[2],O_RDONLY))) {
fprintf(stderr,"Error: unable to open tty %s\n",argv[2]);
exit(-1);
}
lock=!strcmp(argv[1],"lock");
printf("Ioctl VT_%sLOCKSWITCH returned %d\n",lock?"":"UN",
ioctl(fd,lock?VT_LOCKSWITCH:VT_UNLOCKSWITCH));
return(0);
}
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: SuperProbe
On Sat, 16 Feb 2002, Ben Craft wrote: >Date: Sat, 16 Feb 2002 14:45:38 -0500 >From: Ben Craft <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Content-Type: text/plain; charset=iso-8859-1 >List-Id: General X Discussion >Subject: SuperProbe > >Where is the current version of SuperProbe? SuperProbe no longer exists. It was deprecated, and removed from XFree86 sources as of 4.2.0. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
Andy Sparrow wrote: > > > Maybe this could be an alternate solution, can i force X to run on tty1? So > > if a Ctrl-Alt-F1 occured nothing would happen since they are already on 1? > > Hmm, actually, I don't see why you couldn't disable all the gettys & run > [xwgk]dm as a display manager, which will take the first "free" VTY, if none > is specified. > > So, just run a display manager out of a startup script at boottime, without > specifying a VTY for it to run on, and it'll start on the first VTY. > > Which, thinking about it, might be why no-one implemented 'DontSwitch'. > Because it's not necessary - as soon as X is a one-way trip, you may as well > not have a text mode console at all because you have no way of getting back to > it once X is running - so don't run a text console, just start a display > manager instead :) This will result in no available text consoles, but you can still use Crtl-Alt-Fn to switch to a blank, unused VT. He doesn't want that to be available. I think all that is needed is a simple utility to lock the VT. The same code would be used in XFree86, but it doesn't need to be in XFree86 to work: ioctl (fd, VT_LOCKSWITCH, 1); /* lock the switch */ ioctl (fd, VT_UNLOCKSWITCH, 1); /* unlock it again */ Joe Krahn ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon: V_BIOS
On Sat, 16 Feb 2002, Jonathan C. Nicklin wrote: > All, > I am trying to debug the dual head freeze I described > in a previous post and I noticed something interesting > of which I am curious if there is an explanation. I have > found that the first time I start the X server, the logs dont > inidicate any errors, but, if I immediately restart the > server, the logs inidicate the following: > > (II) RADEON(1): PCI bus 1 card 0 func 0 > (**) RADEON(1): Depth 16, (--) framebuffer bpp 16 > (II) RADEON(1): Pixel depth = 16 bits stored in 2 bytes (16 bpp pixmaps) > > (==) RADEON(1): Default visual is TrueColor > (==) RADEON(1): RGB weight 565 > (II) RADEON(1): Using 6 bits per RGB (8 bit DAC) > (II) Loading sub module "int10" > (II) LoadModule: "int10" > (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a > (II) RADEON(1): initializing int10 > (EE) RADEON(1): Cannot read V_BIOS > (--) RADEON(1): Chipset: "ATI Radeon QD (AGP)" (ChipID = 0x5144) > (--) RADEON(1): Linear framebuffer at 0xd800 > (--) RADEON(1): MMIO registers at 0xff88 > (--) RADEON(1): BIOS at 0xff86 > (--) RADEON(1): VideoRAM: 32768 kByte (64-bit DDR SDRAM) > (WW) RADEON(1): Video BIOS not detected in PCI space! > (WW) RADEON(1): Attempting to read Video BIOS from legacy ISA space! > (II) RADEON(1): Primary Display == Type 1 > > This error is not fatal but it is odd that this message > does not appear when starting X after a warm or cold > reset. > > Does anyone have any clue why this might happen? I've seen this behaviour is well. What happens (AFAIK) is that initially the card is "cold" and you can read BIOS from PCI space. But once it was booted by the Xserver its BIOS is mapped into ISA space i.e. with segment 0xC000 for DOS compatibility. Vladimir Dergachev > > thanks, > Jonathan Nicklin > > ps. this specific card is a AIW AGP > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
> Maybe this could be an alternate solution, can i force X to run on tty1? So > if a Ctrl-Alt-F1 occured nothing would happen since they are already on 1? Hmm, actually, I don't see why you couldn't disable all the gettys & run [xwgk]dm as a display manager, which will take the first "free" VTY, if none is specified. So, just run a display manager out of a startup script at boottime, without specifying a VTY for it to run on, and it'll start on the first VTY. Which, thinking about it, might be why no-one implemented 'DontSwitch'. Because it's not necessary - as soon as X is a one-way trip, you may as well not have a text mode console at all because you have no way of getting back to it once X is running - so don't run a text console, just start a display manager instead :) I'd suggest that you don't disable Ctrl+Alt+Backspace though, so that if the X server wedged for any reason, you (the user) could re-start it. I don't know about the others, but I know that wdm supports a default user (including password), which might also be useful in a kiosk mode. Cheers, AS msg04205/pgp0.pgp Description: PGP signature
Re: [Xpert]S3 Trio problem with 4.2.0
Hi all.
I have a Trio 32/64/64V+ 0x8811 here.
In 8bit modes the color-index doesn't seem to be written to the card
and so the colors are not correct ("Alien mode").
16bit modes seem to work correct.
In 24bit modes the card doesn't seem to generate a video signal - my
monitor goes into no-signal standby mode ...
In dual-head mode with an ATI-Mach64 AGP as primary card, the s3 card
generates a vaild viedo-signal (in 16bit mode - 1024x786), but the
screen is black. (yes - I know how to configure a dual-head mode
... ;-)
on: Sat, 2 Feb 2002 15:27:45 -0800 (PST),
Ani Joshi <[EMAIL PROTECTED]> wrote:
>
> Can you send me your /var/log/XFree86.0.log. Its possible you are either
> using vesa or vga driver and not the "s3" driver, since the Trio64V2 (aka
> Trio64V2_DXGX) isn't supported inthe s3 driver right now. The only Trio
> PCI id's that s3 driver will recognize are:
>
> Trio 32/64/64V+ 0x8811
> Trio Aurora64VP 0x8812
>
> I'll try and hack in support for the 64V2 and place a driver for testing.
>
>
> ani
>
> On Fri, 1 Feb 2002, Mauricio Martinez wrote:
>
> > I have an S3 Trio64V2 card with 2048 Kb RAM.
> >
> > Everything seems to be OK, even the xf86cfg program
> > works correctly.
> >
> > 1024x768 and all other modes at 8 bit work great.
> >
> > However, 1024x768 @ 16 bit represents the screen as
> > vertical strip lines with ghost images. (and possibly
> > other resolutions).
> >
> > Is this a bug, or am I missing something in the setup?
> > Thank you.
k33p h4ck1n6
René
--
René Rebe (Registered Linux user: #248718 )
eMail:[EMAIL PROTECTED]
[EMAIL PROTECTED]
Homepage: http://drocklinux.dyndns.org/rene/
Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
On Sat, 16 Feb 2002, Andy Sparrow wrote: > > On Sat, 16 Feb 2002, Christopher W. Allermann wrote: > > > > > I'm stuck with a little bit of a problem here and have been unable > to find a > > > suitable solution. > > > >You might have to hack the server to do this. There are already > > config file options to prevent Ctrl-Alt-backspace and Ctrl-Alt-+/-, > > but there isn't one for Ctrl-Alt-F#. Maybe there was a reason for > > that, I don't remember. This isn't the first time somebody wanted > > to do this. > > Actually, someone asked me about this recently, and I was surprised to > discover that it didn't exist too. It seems to me that it should be a > standard option, as there's (at least) two cases where it would be both > valid > and useful: > > i)Your hardware won't switch cleanly back to text mode from X[1] > > ii) You're setting up a kiosk-mode machine > > As you say, this also isn't the first time that somebody wanted this, so > > there's obviously a grass-roots requirement for it :) > > I'm currently working on a patch for this, and I'd appreciate some > advice; I > believe that such an option (lets call it 'DontSwitch') should disable > VT > switching for all OSes that support that functionality (including the > ones > that use the VTSysreq method of doing it). [...] > Any comments? > "DontSwitch" is an ambiguous name. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
I'm a little confused. I am trying to run this boxes in a kiosok type mode. The application of this chvt terminal. Will this throw them back to tty7 (where is is running) or will it move the tty that X is running on. Making X run on tty1. Maybe this could be an alternate solution, can i force X to run on tty1? So if a Ctrl-Alt-F1 occured nothing would happen since they are already on 1? Please excuse my ignorance on this subject, i've always been used to working in console mode, so I am not familiar with the intricate working of the X system. Chris Allermann - [EMAIL PROTECTED] - Original Message - From: "Syed Irfan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 16, 2002 6:44 PM Subject: Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X > for disabling switching vt > try chvt vtnumber & (eg: chvt 1 &)if ur x is running > in tty1 in your script that should do the trick, i > came with full install of redhat 7.2, try man chvt, or > google is your friend > > hope this helps, i have seen just too many people ask > this question > > hth > syed irfan > crazycrusoe > > --- Andy Sparrow <[EMAIL PROTECTED]> wrote: > > > On Sat, 16 Feb 2002, Christopher W. Allermann > > wrote: > > > > > > > I'm stuck with a little bit of a problem here > > and have been unable to find a > > > > suitable solution. > > > > > >You might have to hack the server to do this. > > There are already > > > config file options to prevent Ctrl-Alt-backspace > > and Ctrl-Alt-+/-, > > > but there isn't one for Ctrl-Alt-F#. Maybe there > > was a reason for > > > that, I don't remember. This isn't the first time > > somebody wanted > > > to do this. > > > > Actually, someone asked me about this recently, and > > I was surprised to > > discover that it didn't exist too. It seems to me > > that it should be a > > standard option, as there's (at least) two cases > > where it would be both valid > > and useful: > > > > i) Your hardware won't switch cleanly back to text > > mode from X[1] > > > > ii) You're setting up a kiosk-mode machine > > > > As you say, this also isn't the first time that > > somebody wanted this, so > > there's obviously a grass-roots requirement for it > > :) > > > > I'm currently working on a patch for this, and I'd > > appreciate some advice; I > > believe that such an option (lets call it > > 'DontSwitch') should disable VT > > switching for all OSes that support that > > functionality (including the ones > > that use the VTSysreq method of doing it). > > > > As there's already a runtime switch to control this > > (which already DTRT when > > DRI has is in fullscreen mode), I also think the > > neatest way to add this > > functionality would be to add 'VTSwitchEnable' to > > the tests for the rest of > > the OSes that support VT switching, and set if from > > the config file, if the > > option is present. > > > > Any comments? > > > > Cheers, > > > > AS > > > > [1] Some Dell laptop users are stuck with this > > apparently, a switch back to > > text mode hoses you totally. Ick. > > > > > > > > > ATTACHMENT part 2 application/pgp-signature > > > > = > = > CrazyCrusoe > Hackerd00d > > http://members.linuxstart.com/openweb > = > > __ > Do You Yahoo!? > Yahoo! Sports - Coverage of the 2002 Olympic Games > http://sports.yahoo.com > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
for disabling switching vt try chvt vtnumber & (eg: chvt 1 &)if ur x is running in tty1 in your script that should do the trick, i came with full install of redhat 7.2, try man chvt, or google is your friend hope this helps, i have seen just too many people ask this question hth syed irfan crazycrusoe --- Andy Sparrow <[EMAIL PROTECTED]> wrote: > > On Sat, 16 Feb 2002, Christopher W. Allermann > wrote: > > > > > I'm stuck with a little bit of a problem here > and have been unable to find a > > > suitable solution. > > > >You might have to hack the server to do this. > There are already > > config file options to prevent Ctrl-Alt-backspace > and Ctrl-Alt-+/-, > > but there isn't one for Ctrl-Alt-F#. Maybe there > was a reason for > > that, I don't remember. This isn't the first time > somebody wanted > > to do this. > > Actually, someone asked me about this recently, and > I was surprised to > discover that it didn't exist too. It seems to me > that it should be a > standard option, as there's (at least) two cases > where it would be both valid > and useful: > > i)Your hardware won't switch cleanly back to text > mode from X[1] > > ii) You're setting up a kiosk-mode machine > > As you say, this also isn't the first time that > somebody wanted this, so > there's obviously a grass-roots requirement for it > :) > > I'm currently working on a patch for this, and I'd > appreciate some advice; I > believe that such an option (lets call it > 'DontSwitch') should disable VT > switching for all OSes that support that > functionality (including the ones > that use the VTSysreq method of doing it). > > As there's already a runtime switch to control this > (which already DTRT when > DRI has is in fullscreen mode), I also think the > neatest way to add this > functionality would be to add 'VTSwitchEnable' to > the tests for the rest of > the OSes that support VT switching, and set if from > the config file, if the > option is present. > > Any comments? > > Cheers, > > AS > > [1] Some Dell laptop users are stuck with this > apparently, a switch back to > text mode hoses you totally. Ick. > > > > ATTACHMENT part 2 application/pgp-signature = = CrazyCrusoe Hackerd00d http://members.linuxstart.com/openweb = __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
> On Sat, 16 Feb 2002, Christopher W. Allermann wrote: > > > I'm stuck with a little bit of a problem here and have been unable to find a > > suitable solution. > >You might have to hack the server to do this. There are already > config file options to prevent Ctrl-Alt-backspace and Ctrl-Alt-+/-, > but there isn't one for Ctrl-Alt-F#. Maybe there was a reason for > that, I don't remember. This isn't the first time somebody wanted > to do this. Actually, someone asked me about this recently, and I was surprised to discover that it didn't exist too. It seems to me that it should be a standard option, as there's (at least) two cases where it would be both valid and useful: i) Your hardware won't switch cleanly back to text mode from X[1] ii) You're setting up a kiosk-mode machine As you say, this also isn't the first time that somebody wanted this, so there's obviously a grass-roots requirement for it :) I'm currently working on a patch for this, and I'd appreciate some advice; I believe that such an option (lets call it 'DontSwitch') should disable VT switching for all OSes that support that functionality (including the ones that use the VTSysreq method of doing it). As there's already a runtime switch to control this (which already DTRT when DRI has is in fullscreen mode), I also think the neatest way to add this functionality would be to add 'VTSwitchEnable' to the tests for the rest of the OSes that support VT switching, and set if from the config file, if the option is present. Any comments? Cheers, AS [1] Some Dell laptop users are stuck with this apparently, a switch back to text mode hoses you totally. Ick. msg04200/pgp0.pgp Description: PGP signature
Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
Yeah, I already have the "DontZoom" and "DontZap" options specified. Was hoping theere was some easy methord for the F1 disable. - Original Message - From: "Mark Vojkovich" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 16, 2002 5:02 PM Subject: Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X > On Sat, 16 Feb 2002, Christopher W. Allermann wrote: > > > I'm stuck with a little bit of a problem here and have been unable to find a > > suitable solution. > >You might have to hack the server to do this. There are already > config file options to prevent Ctrl-Alt-backspace and Ctrl-Alt-+/-, > but there isn't one for Ctrl-Alt-F#. Maybe there was a reason for > that, I don't remember. This isn't the first time somebody wanted > to do this. > > > Mark. > > > > > > I'm trying to deploy a few Linux based terminals. I want to disable all > > tty's but the one X is running on. I've modified my /etc/inttab, and killed > > getty on the tty's, and have X starting at boot up. My problem is that a > > user is still able to Ctrl-Alt-F1 out of X. While getty is not running > > there I am not concerned about users logging in there. However I am a bit > > worried that users would become flustered if they "Accidentally" got out to > > tty1 and could not get back into X. I am looking for a simple way to > > prevent this from happening. > > > > I'm running Debian 2.2 Potato, Linux Kernel 2.2.17 and XFree86 3.3.6 (I > > know its not the latest, sorry about this. I'm in a rush to deploy, can > > always upgrade later.) > > > > Any help would be appreciated. > > > > Chris Allermann - [EMAIL PROTECTED] > > > > ___ > > Xpert mailing list > > [EMAIL PROTECTED] > > http://XFree86.Org/mailman/listinfo/xpert > > > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
On Sat, 16 Feb 2002, Christopher W. Allermann wrote: > I'm stuck with a little bit of a problem here and have been unable to find a > suitable solution. You might have to hack the server to do this. There are already config file options to prevent Ctrl-Alt-backspace and Ctrl-Alt-+/-, but there isn't one for Ctrl-Alt-F#. Maybe there was a reason for that, I don't remember. This isn't the first time somebody wanted to do this. Mark. > > I'm trying to deploy a few Linux based terminals. I want to disable all > tty's but the one X is running on. I've modified my /etc/inttab, and killed > getty on the tty's, and have X starting at boot up. My problem is that a > user is still able to Ctrl-Alt-F1 out of X. While getty is not running > there I am not concerned about users logging in there. However I am a bit > worried that users would become flustered if they "Accidentally" got out to > tty1 and could not get back into X. I am looking for a simple way to > prevent this from happening. > > I'm running Debian 2.2 Potato, Linux Kernel 2.2.17 and XFree86 3.3.6 (I > know its not the latest, sorry about this. I'm in a rush to deploy, can > always upgrade later.) > > Any help would be appreciated. > > Chris Allermann - [EMAIL PROTECTED] > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
I'm stuck with a little bit of a problem here and have been unable to find a suitable solution. I'm trying to deploy a few Linux based terminals. I want to disable all tty's but the one X is running on. I've modified my /etc/inttab, and killed getty on the tty's, and have X starting at boot up. My problem is that a user is still able to Ctrl-Alt-F1 out of X. While getty is not running there I am not concerned about users logging in there. However I am a bit worried that users would become flustered if they "Accidentally" got out to tty1 and could not get back into X. I am looking for a simple way to prevent this from happening. I'm running Debian 2.2 Potato, Linux Kernel 2.2.17 and XFree86 3.3.6 (I know its not the latest, sorry about this. I'm in a rush to deploy, can always upgrade later.) Any help would be appreciated. Chris Allermann - [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SuperProbe
On Sat, 16 Feb 2002 [EMAIL PROTECTED] wrote: > Where is the current version of SuperProbe? > Thanks. I believe SuperProbe has been deprecated (there is no current version, only past versions). Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]SuperProbe
Where is the current version of SuperProbe? Thanks. -- Please REPLY to: [EMAIL PROTECTED] DO NOT send mail to netscape.net __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Radeon: V_BIOS
All, I am trying to debug the dual head freeze I described in a previous post and I noticed something interesting of which I am curious if there is an explanation. I have found that the first time I start the X server, the logs dont inidicate any errors, but, if I immediately restart the server, the logs inidicate the following: (II) RADEON(1): PCI bus 1 card 0 func 0 (**) RADEON(1): Depth 16, (--) framebuffer bpp 16 (II) RADEON(1): Pixel depth = 16 bits stored in 2 bytes (16 bpp pixmaps) (==) RADEON(1): Default visual is TrueColor (==) RADEON(1): RGB weight 565 (II) RADEON(1): Using 6 bits per RGB (8 bit DAC) (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a (II) RADEON(1): initializing int10 (EE) RADEON(1): Cannot read V_BIOS (--) RADEON(1): Chipset: "ATI Radeon QD (AGP)" (ChipID = 0x5144) (--) RADEON(1): Linear framebuffer at 0xd800 (--) RADEON(1): MMIO registers at 0xff88 (--) RADEON(1): BIOS at 0xff86 (--) RADEON(1): VideoRAM: 32768 kByte (64-bit DDR SDRAM) (WW) RADEON(1): Video BIOS not detected in PCI space! (WW) RADEON(1): Attempting to read Video BIOS from legacy ISA space! (II) RADEON(1): Primary Display == Type 1 This error is not fatal but it is odd that this message does not appear when starting X after a warm or cold reset. Does anyone have any clue why this might happen? thanks, Jonathan Nicklin ps. this specific card is a AIW AGP ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]GCC 3.0.3 and X 4.2.0 compile problem
Kevin Clevenger wrote (in a message from Wednesday 13) > > When compling X 4.2.0 with gcc 3.0.3 on a glibc 2.2.5 system I get the > following. Using gcc 2.95.3 on the same system compiles correctly. I have > tried altering the -traditional flag in the imakemdep.h file to no avail. Other people I've asked say that cpp in gcc 3.0 still supports -traditional. What's special about your configuration that makes it not support -traditional ? The -traditional flag is required with gcc's cpp because otherwise it does silly things to imake input. (Adds white space before and after macro expansion results, tries to interpret backslashes where it should leave them alone, etc.) It's really unfortnate if the GNU people have removed the -traditional option to cpp in gcc 3.0. XFree86 will have to provide a non broken C pre-processor for imake to work with gcc 3, in this case. Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]4.2.0 R128 hanging
Michel Dänzer wrote: > > On Sam, 2002-02-16 at 16:50, Joe Krahn wrote: > > > > > > > Here's an example backtrace, that seems to me like somthing > > > > deeper than XFree86 code being at fault: > > > > > > > > (gdb) bt > > > > #0 0x40139012 in __writev (fd=20, vector=0xb6fc, count=1) > > > > at ../sysdeps/unix/sysv/linux/writev.c:51 > > > > #1 0x080d5ad4 in _XSERVTransSocketWritev () > > > > #2 0x080d61cc in _XSERVTransWritev () > > > > #3 0x080d0248 in StandardFlushClient () > > > > #4 0x080cea8f in CloseDownConnection () > > > > #5 0x080b2f69 in CloseDownClient () > > > > #6 0x080addbd in Dispatch () > > > > #7 0x080bd6d8 in main () > > > > #8 0x4006e627 in __libc_start_main (main=0x80bd1f0 , argc=1, > > > > ubp_av=0xbc04, init=0x806cc5c <_init>, fini=0x816f94c <_fini>, > > > > rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbbfc) > > > > at ../sysdeps/generic/libc-start.c:129 > > > > > > A backtrace from the server would probably be more interesting, or does > > > only the client hang? > > This is a backtrace from the server, > > D'oh, should have noticed. :) > > > but it's not the XFree86 gdb, so it won't catch module bugs. > > > > I tried installing RedHat's RawHide XFree86-4.2, and the same crash > > occurs. I'll re-install mine, which has debug symbols, and try > > the XFree86 gdb on it. > > Modules aren't even involved here; the hang occurs in a glibc function > so it seems the problem isn't in the X server at all. > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast I was thinking it looked like a glibc bug. The other thing that happens is that vt switching gets messed up. I can no longer switch to a termnial. I'm stuck at vt 7. So, maybe this is what happens if vt access gets cut off? If so, this might even be kernel bug. But, why is only R128 triggering it? I was hoping somebody else has seen the above backtrace and could give me some suggestions. Joe Krahn ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]4.2.0 R128 hanging
you could try logging the vector to the writev call. The problem is probably not in glibc function. Chris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radoen QD
On Wed, 13 Feb 2002, Berry Jeffery A SSgt 552 AGS/LGM wrote: > I am running SuSE 7.3 and I love it! I purchased an ATI Radeon 32 mb video > card only to find out that it has a Radeon QD chipset. Unfortunately > Xfree86 and SuSE only partially support this chipset. So much so that when > I try to enable 3D acceleration I get a black screen or X freezes > completely. I feel Xfree86 is a great product, and regardless of my current > situation I will continue to support this project. I was just wondering if > anyone out there knows what I can do to fix my problem. I've tried > everything and I'm just running in circles. Also, does the new 4.2 version > of Xfree86 support my chip set? Any help in this matter would be greatly > appretiated. Which XFree86 version are you running ? I believe it should work fine with 4.2.0. Vladimir Dergachev > > Thanks, > > Jeff > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]4.2.0 R128 hanging
On Sam, 2002-02-16 at 16:50, Joe Krahn wrote: > > > > > Here's an example backtrace, that seems to me like somthing > > > deeper than XFree86 code being at fault: > > > > > > (gdb) bt > > > #0 0x40139012 in __writev (fd=20, vector=0xb6fc, count=1) > > > at ../sysdeps/unix/sysv/linux/writev.c:51 > > > #1 0x080d5ad4 in _XSERVTransSocketWritev () > > > #2 0x080d61cc in _XSERVTransWritev () > > > #3 0x080d0248 in StandardFlushClient () > > > #4 0x080cea8f in CloseDownConnection () > > > #5 0x080b2f69 in CloseDownClient () > > > #6 0x080addbd in Dispatch () > > > #7 0x080bd6d8 in main () > > > #8 0x4006e627 in __libc_start_main (main=0x80bd1f0 , argc=1, > > > ubp_av=0xbc04, init=0x806cc5c <_init>, fini=0x816f94c <_fini>, > > > rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbbfc) > > > at ../sysdeps/generic/libc-start.c:129 > > > > A backtrace from the server would probably be more interesting, or does > > only the client hang? > This is a backtrace from the server, D'oh, should have noticed. :) > but it's not the XFree86 gdb, so it won't catch module bugs. > > I tried installing RedHat's RawHide XFree86-4.2, and the same crash > occurs. I'll re-install mine, which has debug symbols, and try > the XFree86 gdb on it. Modules aren't even involved here; the hang occurs in a glibc function so it seems the problem isn't in the X server at all. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]4.2.0 R128 hanging
Michel Dänzer wrote: > > On Sam, 2002-02-16 at 04:04, Joe Krahn wrote: > > I've compiled XF 4.2.0 on RedHat 7.2. I get random hangs, > > sometimes when moving long scrollbars, sometimes when closing > > a window. It's on an Athlon, VIA chipset, using RedHat's > > gcc 2.96. Maybe I should use kgcc instead? > > If I disable DRI and add UseCCEFor2D, it still happens. > > Option "UseCCEFor2D" is no more. With DRI enabled, the CCE is always > used for 2D acceleration. > > > Here's an example backtrace, that seems to me like somthing > > deeper than XFree86 code being at fault: > > > > (gdb) bt > > #0 0x40139012 in __writev (fd=20, vector=0xb6fc, count=1) > > at ../sysdeps/unix/sysv/linux/writev.c:51 > > #1 0x080d5ad4 in _XSERVTransSocketWritev () > > #2 0x080d61cc in _XSERVTransWritev () > > #3 0x080d0248 in StandardFlushClient () > > #4 0x080cea8f in CloseDownConnection () > > #5 0x080b2f69 in CloseDownClient () > > #6 0x080addbd in Dispatch () > > #7 0x080bd6d8 in main () > > #8 0x4006e627 in __libc_start_main (main=0x80bd1f0 , argc=1, > > ubp_av=0xbc04, init=0x806cc5c <_init>, fini=0x816f94c <_fini>, > > rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbbfc) > > at ../sysdeps/generic/libc-start.c:129 > > A backtrace from the server would probably be more interesting, or does > only the client hang? This is a backtrace from the server, but it's not the XFree86 gdb, so it won't catch module bugs. I tried installing RedHat's RawHide XFree86-4.2, and the same crash occurs. I'll re-install mine, which has debug symbols, and try the XFree86 gdb on it. Joe Krahn ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]4.2.0 R128 hanging
On Sam, 2002-02-16 at 04:04, Joe Krahn wrote: > I've compiled XF 4.2.0 on RedHat 7.2. I get random hangs, > sometimes when moving long scrollbars, sometimes when closing > a window. It's on an Athlon, VIA chipset, using RedHat's > gcc 2.96. Maybe I should use kgcc instead? > If I disable DRI and add UseCCEFor2D, it still happens. Option "UseCCEFor2D" is no more. With DRI enabled, the CCE is always used for 2D acceleration. > Here's an example backtrace, that seems to me like somthing > deeper than XFree86 code being at fault: > > (gdb) bt > #0 0x40139012 in __writev (fd=20, vector=0xb6fc, count=1) > at ../sysdeps/unix/sysv/linux/writev.c:51 > #1 0x080d5ad4 in _XSERVTransSocketWritev () > #2 0x080d61cc in _XSERVTransWritev () > #3 0x080d0248 in StandardFlushClient () > #4 0x080cea8f in CloseDownConnection () > #5 0x080b2f69 in CloseDownClient () > #6 0x080addbd in Dispatch () > #7 0x080bd6d8 in main () > #8 0x4006e627 in __libc_start_main (main=0x80bd1f0 , argc=1, > ubp_av=0xbc04, init=0x806cc5c <_init>, fini=0x816f94c <_fini>, > rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbbfc) > at ../sysdeps/generic/libc-start.c:129 A backtrace from the server would probably be more interesting, or does only the client hang? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon VE (or any Radeon) in Dual Head Mode
On Sam, 2002-02-16 at 06:32, Chris wrote: > I'm shortly going to be writing a review on some Radeon VE hardware under > XFree86 on Linux and one of the questions that came up is the ability to > handle multiple monitors off the dual SVGA heads on the Radeon VE in > specific and the Radeon line in general. I just need to know if it's > feasable to set up dual monitors off a single card with the Radeon VE or any > of the Radeon cards currently, or if the "radeon" server will handle this in > the future. This is supported in 4.2.0 via Screen entries in the device sections. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]4.2.0 R128 hanging
I've compiled XF 4.2.0 on RedHat 7.2. I get random hangs, sometimes when moving long scrollbars, sometimes when closing a window. It's on an Athlon, VIA chipset, using RedHat's gcc 2.96. Maybe I should use kgcc instead? If I disable DRI and add UseCCEFor2D, it still happens. Is anyone else using 4.2, successfully or not, with R128 and RedHat 7.2? Here's an example backtrace, that seems to me like somthing deeper than XFree86 code being at fault: (gdb) bt #0 0x40139012 in __writev (fd=20, vector=0xb6fc, count=1) at ../sysdeps/unix/sysv/linux/writev.c:51 #1 0x080d5ad4 in _XSERVTransSocketWritev () #2 0x080d61cc in _XSERVTransWritev () #3 0x080d0248 in StandardFlushClient () #4 0x080cea8f in CloseDownConnection () #5 0x080b2f69 in CloseDownClient () #6 0x080addbd in Dispatch () #7 0x080bd6d8 in main () #8 0x4006e627 in __libc_start_main (main=0x80bd1f0 , argc=1, ubp_av=0xbc04, init=0x806cc5c <_init>, fini=0x816f94c <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbbfc) at ../sysdeps/generic/libc-start.c:129 I updated from CVS, still hangs. But, there is a glibc update from RedHat which I haven't applied yet. I'll try that with kgcc, and maybe with gcc3. Joe Krahn ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
