Date: Tue, 22 Dec 2015 00:21:21 +0000 From: spellberg_robert <emailrob@emailrob.com> To: freebsd-questions@freebsd.org Cc: emailrob@emailrob.com Subject: f_10.2_i386 "ctrl_alt_bksp" kills all video , not just x . Message-ID: <56789781.6080206@emailrob.com>
next in thread | raw e-mail | index | archive | help
howdy , folks ---
this question concerns a box that is running f_10.2_i386 and x_7.7 .
previously , this box ran
f_9.3_amd64 and --that-- release's version of x_7.7 .
however , the "package"s on that 9.3 were clobbered by "port"s ,
rendering it unusable ;
thus , after creating a replacement 9.3_amd64 box [ see below ] ,
that clobbered box became available for later use .
until it got clobbered , it ran 9.3 and x just fine , thank you .
no hardware was changed
[ except , each fresh install gets virgin hard_drives ] ;
no animals were harmed .
a different box , driving a different monitor , is running 9.3_amd64
[ this box replaced the clobbered box and
it has packages , --only-- , installed ,
such as x , firefox , thunderbird and , of course ,
a menagerie of dependencies
] .
the two boxes have identical 64_bit hardware :
antec case and ps , intel mobo and cpu , et_cetera .
the two monitors are the same make and model [ 1920x1200 lcd ] .
both are driven with the "dvi" connector
[ having the "blade" contact , at one end ; not the 15_pin "vga" ] ;
however , i do not suspect that this matters .
both , the 9.3 and the 10.2 , are running the x_7.7 that is
supplied in the package that is
included in their fbsd_dvd image_files , respectively , that are
used for their initial boots , respectively .
for both , of these two installs , x starts and runs as expected ;
so far , so good .
the problem is this :
on 10.2 , <ctrl_alt_bksp> is not recognized , as a command .
"xterm" says that i typed "\0377" [ or "/0377" , i forget which ] .
hmmm ... , what to do ?
that is easy : try the obvious .
initially , after "ps" gave me some "pid"s ,
methodically , i "kill"ed x_related processes , until x died .
surprise , surprise .
apparently , now , this disables the video output , because
the monitor reports , "monitor is going to sleep" , which it does .
further ,
none of the <alt_fn> keys take me to a different virtual terminal ,
as they do before i invoke "startx" .
notwithstanding the video loss , though ,
the 10.2 box is still "up" , because
i can "ssh" over to it , from the 9.3 box .
so , i got the bright_idea of going to "http://x.org" ,
to see , there , what there is to see , err ... , there .
following the links from their top_level web_page , i get to
"www.x.org/releases/X11R7.7/doc"
.
this top_level documentation page is dated 2012_jun_06_wed .
in the "txt" version of the "xkb configuration guide" [ 2010_nov ] ,
we find , at the end of the sub_section , "basic configuration"
[ about half_way down the page ] ,
Option "XKbOptions" "terminate:ctrl_alt_bksp"
.
this one , i have seen before .
in my "/etc/xorg.conf" , i first used this for
f__7.4 / x_7.4 [ retired ] and it has remained for
f__8.4 / x_7.5.2 [ current ] ,
f__9.3 / x_7.7 [ current ] and
f_10.2 / x_7.7 [ problem ] .
continuing , on the last line of this sub_section , we find
setxkbmap -option "terminate:cfrl_alt_bksp"
.
this one is new [ to me , anyway ] .
so , i got the bright_idea to try this ,
just to see what happens [ or not ]
[ i get lotsa bright_ideas ; i like to live dangerously ] .
eureka !
x recognized "ctrl_alt_bksp" as a command .
you guessed it .
promptly , the video was disabled and
the monitor went to sleep [ snicker ; sigh ] .
i believe that this is the same response as
that which was generated by killing processes .
well , the recognition is --some-- kind of progress .
i should point out that
recognizing ctrl_alt_bksp is not critical ,
if i can kill x by using "kill -9 pid" ;
however , it --is-- convenient .
i want to restore the several virtual terminals that existed
before i invoked "startx" .
at this point , i am stuck for ideas
[ check my files ; read the x documents ; et_cetera ] .
also , i have been looking at the archives of "-questions@" ,
but , mostly , for answers to a different problem
[ more on that , under separate cover ] .
none_the_less , based upon the subject line ,
i read anything that looked like it might apply to
something that i do .
perhaps , there was a small change in x_7.7 or in fbsd , after 9.3 .
you know the kind that i mean : fix "a" or improve "b" ,
but , inadvertently , break "c" .
could this be related to that new "vt" thing ?
"vt" looks promising , from what i have read ,
but , i have not found the time , as yet , to investigate it .
similarly , more broadly ,
perhaps there is a "silent" dependency upon some new "thingy" ,
that most fbsd users are installing , but , which i am not ,
because , for example , i am unaware of its existence .
i observe that the x documentation
pre_dates the releases of 9.3 and 10.2 ;
therefore , i am not convinced that x is the problem ,
although , i may be wrong .
further , my "/etc/xorg.conf" , for 10.2 , is identical to
that which is used , for 9.3 , because
i copy the file from release to release [ "xinitrc" , also ]
[ except , of course , to
update the comments , for the new release , and to
make any changes that are necessitated by the folks at x.org ;
while it --was-- necessary to make some changes ,
when going from f_8.4/x_7.5.2 to f_9.3/x_7.7 ,
no changes were made when going from f_9.3/x_7.7 to f_10.2/x_7.7
] .
remember , the 10.2 box , where x has this behavior , is
the --same-- box that had the clobbered 9.3 install ,
where x worked [ and still does , on the replacement box ] just fine .
has anyone any thoughts ?
thanking everyone , for any assistance , in advance , i remain
sincerely yours
rob
p . s . ---
it is late in my day and
i just had a really goofy thought or , perhaps ,
it is an absolutely brilliant idea .
as i said , i can ssh over from another box
[ in fact , one of my xterms is doing just that , at this moment ] .
is there some new command [ i --am-- "su"ed as "root" ] that will
turn on the video system and drive the attached monitor ?
to have to do this from another box --would-- be a kluge , but ,
in the short_term , it would be a work_around ,
until a better approach is determined .
the logical place for this [ to my mind ] is vidcontrol(1) .
i just checked the man_page , but , nothing like that exists .
on_the_other_hand ,
reading that page --did-- give me another bright_idea .
perhaps ,
some kind of screensaver/blanking system has been enabled ,
without my knowledge
[ i always turn this stuff off in my "rc.conf" ;
now that i no longer worry about
crt_filament [ heater , actually ] thermal metal_fatigue ,
i just turn off the monitor
] .
to test this hypothesis ,
on the assumption that there --is-- a virtual terminal there ,
i typed <alt_f1> [ to be certain of the terminal ] , then <enter> .
alas , the monitor remains "on" and in "standby" mode
[ no signal on the cable ] .
then , because i was thinking about the file ,
i checked my "rc.conf" , just to be sure .
for the "system console options" , i have made only these over_rides :
keyrate="fast"
cursor="blink"
blanktime="NO"
moused_enable="YES"
.
i would not expect three , of these four , to be involved .
other_wise , i am using the defaults .
at this point , i am out of ideas .
i have been revising this post , every now_and_again , all day long ,
as i think of tid_bits of additional information that may be useful .
my suspicion is that
this behavior is being caused by something that is insanely simple .
[ sorry about the length of this post ;
at an early age , i was taught to be thorough , to be precise and
to write things down .
]
rob
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56789781.6080206>