nanogui: Thread: My newbee question of the day ...

Hi guys,

Anybody can tell me what this code snip does exactly (taken from fb_open
in src_fb.c)

Actually, what is this ioctl doing *exactly* ?

 /* open tty, enter graphics mode*/
 tty = open ("/dev/tty0", O_RDWR);
 if(tty < 0) {
  failmsg("can't open /dev/tty0: %m");
  goto fail;
 }
 if(ioctl (tty, KDSETMODE, KD_GRAPHICS) == -1) {
  failmsg("setting graphics mode: %m");
  close(tty);
  goto fail;
 }
 close(tty);


Thanks,

Martin Jolicoeur
GVT Project
####@####.####

Martin Jolicoeur ####@####.#### writes:

> Actually, what is this ioctl doing *exactly* ?
> 
>  if(ioctl (tty, KDSETMODE, KD_GRAPHICS) == -1) {
>   failmsg("setting graphics mode: %m");
>   close(tty);
>   goto fail;
>  }

IIRC, at least one of the things it does is tell the kernel that
a graphics mode has been entered, discouragin the kernel from
messing with the console.  ISTR that it turns off the cursor too.

To find out exactly what it does, your best bet is to read kernel
source.  The fb source is pretty easy to read IMO.

Martin Jolicoeur wrote:

> Hi guys,
>
> Anybody can tell me what this code snip does exactly (taken from fb_open
> in src_fb.c)
>
> Actually, what is this ioctl doing *exactly* ?

A ioctl function is used to "talk" to a device.
When you want to read or write to a specific device, you use
this function.
ioctl is called with 3 parameters:
    - the file descriptor of the device.
    - the ioctl number.
    - a parameter.

To see the source code, in this case, open the drivers/char/vt.c in your
kernel
You'll find a a line that handle the parameter KD_GRAPHICS for the ioctl
(function) KDSETMODE.

It's the same for frame buffer.
You use ioctl to get screen informations :
ioctl(fb,FBIOGET_FSCREENINFO,&fb_fix);

And you can see in video/fbmem.c the details.

>
>
>  /* open tty, enter graphics mode*/
>  tty = open ("/dev/tty0", O_RDWR);
>  if(tty < 0) {
>   failmsg("can't open /dev/tty0: %m");
>   goto fail;
>  }
>  if(ioctl (tty, KDSETMODE, KD_GRAPHICS) == -1) {
>   failmsg("setting graphics mode: %m");
>   close(tty);
>   goto fail;
>  }
>  close(tty);
>
> Thanks,
>
> Martin Jolicoeur
> GVT Project
> ####@####.####
>

: Martin Jolicoeur ####@####.#### writes:
: 
: > Actually, what is this ioctl doing *exactly* ?
: > 
: >  if(ioctl (tty, KDSETMODE, KD_GRAPHICS) == -1) {
: >   failmsg("setting graphics mode: %m");
: >   close(tty);
: >   goto fail;
: >  }
: 
: IIRC, at least one of the things it does is tell the kernel that
: a graphics mode has been entered, discouragin the kernel from
: messing with the console.  ISTR that it turns off the cursor too.

Yes, correct.  But the big thing is that it actually causes the kernel
to SWITCH into graphics mode if not already.  That is, the kernel
may be compiled to support text and or graphics console operation.
If the console is running in text mode, the above ioctl
causes the kernel to talk to the video card and switch it from
text to graphics mode.  The switch back is handled by another
ioctl later on in the same file when Microwindows exits.

If the console is already running in graphics mode, then nothing
happens.


Now, in addition to this, the code in src/drivers/vtswitch.c deals
with the signals that the kernel sends to user programs when the
user switches consoles via ALT-Fn keys.  That is, the user program
tells the kernel which signal to send it, and then the kernel will send
a signal to ask whether switching is OK.  The user program must respond
with an ioctl to acknowledge the switch.  Until acknowledged, the
kernel tty drivers won't switch consoles.  I recently changed this
code to use SIGUNUSED rather than SIGUSR2, since SIGUSR2
is used by pthreads (I know you're working on a pthreads Microwindows
implementation).  After the user mode ioctl acknowledge, the kernel
then switches into the text or graphics mode of the requested console.
The same thing happens on the way back, so the kernel handles
all text/graphics mode switching.

Finally (since by now I've bored everyone with details, you might
as well know all of them), if Microwindows is drawing at the time
that the console switch request is made, Microwindows delays
the acknowledge ioctl by setting a msec timer until the drawing is completed.
Otherwise, Microwindows would attempt to draw on the new console's
screen.

Hope this clears things up.

Regards,

Greg