f_10.2_i386 "ctrl_alt_bksp" kills all video , not just x .

[spellberg_robert]

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