xref: /illumos-gate/usr/src/man/man4i/visual_io.4i (revision 20a7641f9918de8574b8b3b47dbe35c4bfc78df1)
1.\" Copyright (c) 2005, Sun Microsystems, Inc.  All Rights Reserved
2.\" Copyright 2018, Joyent, Inc.
3.\" The contents of this file are subject to the terms of the
4.\" Common Development and Distribution License (the "License").
5.\" You may not use this file except in compliance with the License.
6.\"
7.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
8.\" or http://www.opensolaris.org/os/licensing.
9.\" See the License for the specific language governing permissions
10.\" and limitations under the License.
11.\"
12.\" When distributing Covered Code, include this CDDL HEADER in each
13.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
14.\" If applicable, add the following below this CDDL HEADER, with the
15.\" fields enclosed by brackets "[]" replaced with your own identifying
16.\" information: Portions Copyright [yyyy] [name of copyright owner]
17.Dd March 13, 2022
18.Dt VISUAL_IO 4I
19.Os
20.Sh NAME
21.Nm visual_io
22.Nd illumos VISUAL I/O control operations
23.Sh SYNOPSIS
24.In sys/visual_io.h
25.Sh DESCRIPTION
26The illumos VISUAL environment defines a small set of ioctls for controlling
27graphics and imaging devices.
28.Pp
29The
30.Dv VIS_GETIDENTIFIER
31ioctl is mandatory and must be implemented in
32device drivers for graphics devices using the illumos VISUAL environment.
33The
34.Dv VIS_GETIDENTIFIER
35ioctl is defined to return a device identifier from the device driver.
36This identifier must be a uniquely-defined string.
37.Pp
38There are two additional sets of ioctls.
39One supports mouse tracking via hardware cursor operations.
40Use of this set is optional, however, if a graphics
41device has hardware cursor support and implements these ioctls, the mouse
42tracking performance is improved.
43The remaining set supports the device acting
44as the system console device.
45Use of this set is optional, but if a graphics device is to be used as the
46system console device, it must implement these ioctls.
47.Pp
48The VISUAL environment also defines interfaces for non-ioctl entry points into
49the driver that the illumos operating environment calls when it is running in
50standalone mode (for example, when using a stand-alone debugger, entering
51the PROM monitor, or when the system panicking).
52These are also known as
53.Dq Polled I/O
54entry points, which operate under an explicit set of restrictions, described below.
55.Sh IOCTLS
56.Bl -tag -width VIS_GETIDENTIFIER -compact
57.It Dv VIS_GETIDENTIFIER
58This
59.Xr ioctl 2
60returns an identifier string to uniquely identify a device
61used in the illumos VISUAL environment.
62This is a mandatory ioctl and must return a unique string.
63We suggest that the name be formed as
64.Ao companysymbol Ac Ns Ao devicetype Ac .
65.Pp
66.Dv VIS_GETIDENTIFIER
67takes a
68.Vt vis_identifier
69structure as its parameter.
70This structure has the form:
71.Bd -literal -offset 2n
72#define VIS_MAXNAMELEN 128
73struct vis_identifier {
74       char name[VIS_MAXNAMELEN];
75};
76.Ed
77.Pp
78.It Dv VIS_GETCURSOR
79.It Dv VIS_SETCURSOR
80These ioctls fetch and set various cursor attributes, using the
81.Vt vis_cursor
82structure.
83.Bd -literal -offset 2n
84struct vis_cursorpos {
85   short x; /* cursor x coordinate */
86   short y; /* cursor y coordinate */
87};
88
89struct vis_cursorcmap {
90    int	version;          /* version */
91    int	reserved;
92    /* red color map elements */
93    unsigned char *red;
94    /* green color map elements */
95    unsigned char *green;
96    /* blue color map elements */
97    unsigned char *blue;
98};
99
100#define VIS_CURSOR_SETCURSOR   0x01  /* set cursor */
101        /* set cursor position */
102#define VIS_CURSOR_SETPOSITION 0x02
103        /* set cursor hot spot */
104#define VIS_CURSOR_SETHOTSPOT  0x04
105        /* set cursor colormap */
106#define VIS_CURSOR_SETCOLORMAP 0x08
107        /* set cursor shape */
108#define VIS_CURSOR_SETSHAPE 0x10
109#define VIS_CURSOR_SETALL	\e
110    (VIS_CURSOR_SETCURSOR | VIS_CURSOR_SETPOSITION | \e
111    VIS_CURSOR_SETHOTSPOT | VIS_CURSOR_SETCOLORMAP | \e
112    VIS_CURSOR_SETSHAPE)
113
114struct vis_cursor {
115    short set;                  /* what to set */
116    short enable;               /* cursor on/off */
117    struct vis_cursorpos pos;   /* cursor position */
118    struct  vis_cursorpos hot;  /* cursor hot spot */
119    struct vis_cursorcmap cmap; /* color map info */
120    /* cursor bitmap size */
121    struct vis_cursorpos size;
122    char  *image;              /* cursor image bits */
123    char  *mask;               /* cursor mask bits */
124};
125.Ed
126.Pp
127The
128.Vt vis_cursorcmap
129structure should contain pointers to two elements,
130specifying the red, green, and blue values for foreground and background.
131.Pp
132.It Dv VIS_SETCURSORPOS
133.It Dv VIS_MOVECURSOR
134These ioctls fetch and move the current cursor position, using the
135.Vt vis_cursorpos
136structure.
137.El
138.Ss "Console Optional Ioctls"
139The following ioctl sets are used by graphics drivers that are part of the
140system console device.
141All of the ioctls must be implemented to be a console device.
142In addition, if the system does not have a prom or the prom goes away
143during boot, the special standalone ioctls (listed below) must also be
144implemented.
145.Pp
146The coordinate system for the console device places 0,0 at the upper left
147corner of the device, with rows increasing toward the bottom of the device and
148columns increasing from left to right.
149.Pp
150.Bl -tag -width VIS_CONSDISPLAY -compact -offset 2n
151.It Dv VIS_PUTCMAP
152.It Dv VIS_GETCMAP
153Set or get color map entries.
154.Pp
155The argument is a pointer to a
156.Vt vis_cmap
157structure, which contains the
158following fields:
159.Bd -literal -offset 2n
160struct vis_cmap {
161    int		index;
162    int		count;
163    uchar_t	*red;
164    uchar_t	*green;
165    uchar_t	*blue;
166}
167.Ed
168.Pp
169.Fa index
170is the starting index in the color map where you want to start
171setting or getting color map entries.
172.Pp
173.Fa count
174is the number of color map entries to set or get.
175It also is the
176size of the
177.Fa red ,
178.Fa green ,
179and
180.Fa blue
181color arrays.
182.Pp
183.Fa *red ,
184.Fa *green ,
185and
186.Fa *blue
187are pointers to unsigned character arrays which contain the color map info to
188set or where the color map info is placed on a get.
189.Pp
190.It Dv VIS_DEVINIT
191Initializes the graphics driver as a console device.
192.Pp
193The argument is a pointer to a
194.Vt vis_devinit
195structure.
196The graphics driver
197is expected to allocate any local state information needed to be a console
198device and fill in this structure.
199.Bd -literal -offset 2n
200struct vis_devinit {
201    int  version;
202    screen_size_t  width;
203    screen_size_t  height;
204    screen_size_t  linebytes;
205    unit_t	   size;
206    int	           depth;
207    short          mode;
208    struct vis_polledio    *polledio;
209    vis_modechg_cb_t       modechg_cb;
210    struct vis_modechg_arg *modechg_arg;
211};
212.Ed
213.Pp
214.Fa version
215is the version of this structure and should be set to
216.Dv VIS_CONS_REV .
217.Pp
218.Fa width
219and
220.Fa height
221are the width and height of the device.
222If
223.Fa mode
224(see below) is
225.Dv VIS_TEXT
226then
227.Fa width
228and
229.Fa height
230are the number of characters wide and high of the device.
231If
232.Fa mode
233is
234.Dv VIS_PIXEL
235then
236.Fa width
237and
238.Fa height
239are the number of pixels wide and high of the device.
240.Pp
241.Fa linebytes
242is the number of bytes per line of the device.
243.Pp
244.Fa size
245is the total size of the device in pixels.
246.Pp
247.Fa depth
248is the pixel depth in device bits.
249Currently supported depths are:
250.Sy 1 ,
251.Sy 4 ,
252.Sy 8
253and
254.Sy 24 .
255.Pp
256.Fa mode
257is the mode of the device.
258Either
259.Dv VIS_PIXEL
260(data to be displayed is in bitmap format) or
261.Dv VIS_TEXT
262(data to be displayed is in ascii format).
263.Pp
264.Fa polledio
265is used to pass the address of the structure containing the
266standalone mode polled I/O entry points to the device driver back to the
267terminal emulator.
268The
269.Vt vis_polledio
270interfaces are described in the
271Console Standalone Entry Points section of this manpage.
272These entry points are where the operating system enters the driver when the
273system is running in standalone mode.
274These functions perform identically to the
275.Dv VIS_CONSDISPLAY ,
276.Dv VIS_CONSCURSOR ,
277and
278.Dv VIS_CONSCOPY
279ioctls, but are called directly by the illumos
280operating environment and must operate under a very strict set of assumptions.
281.Pp
282.Fa modechg_cb
283is a callback function passed from the terminal emulator to
284the framebuffer driver which the frame-buffer driver must call whenever a video
285mode change event occurs that changes the screen height, width or depth.
286The callback takes two arguments, an opaque handle,
287.Fa modechg_arg ,
288and the address of a
289.Vt vis_devinit
290struct containing the new video mode information.
291.Pp
292.Fa modechg_arg
293is an opaque handle passed from the terminal emulator to the
294driver, which the driver must pass back to the terminal emulator as an argument
295to the
296.Fa modechg_cb
297function when the driver notifies the terminal emulator of a video mode change.
298.Pp
299.It Dv VIS_DEVFINI
300Tells the graphics driver that it is no longer the system console device.
301There is no argument to this ioctl.
302The driver is expected to free any locally kept
303state information related to the console.
304.Pp
305.It Dv VIS_CONSCURSOR
306Describes the size and placement of the cursor on the screen.
307The graphics
308driver is expected to display or hide the cursor at the indicated position.
309.Pp
310The argument is a pointer to a
311.Vt vis_conscursor
312structure which contains
313the following fields:
314.Bd -literal -offset 2n
315struct vis_conscursor {
316    screen_pos_t   row;
317    screen_pos_t   col;
318    screen_size_t  width;
319    screen_size_t  height
320    color_t        fg_color;
321    color_t        bg_color;
322    short          action;
323};
324.Ed
325.Pp
326.Fa row
327and
328.Fa col
329are the first row and column (upper left corner of the cursor).
330.Pp
331.Fa width
332and
333.Fa height
334are the width and height of the cursor.
335.Pp
336If
337.Fa mode
338in the
339.Dv VIS_DEVINIT
340ioctl is set to
341.Dv VIS_PIXEL ,
342then
343.Fa col ,
344.Fa row ,
345.Fa width
346and
347.Fa height
348are in pixels.
349If
350.Fa mode
351in the
352.Dv VIS_DEVINIT
353ioctl was set to
354.Dv VIS_TEXT ,
355then
356.Fa col ,
357.Fa row ,
358.Fa width
359and
360.Fa height
361are in characters.
362.Pp
363.Fa fg_color
364and
365.Fa bg_color
366are the foreground and background color map
367indexes to use when the
368.Fa action
369(see below) is set to
370.Dv VIS_DISPLAY_CURSOR .
371.Pp
372.Fa action
373indicates whether to display or hide the cursor.
374It is set to either
375.Dv VIS_HIDE_CURSOR
376or
377.Dv VIS_DISPLAY_CURSOR .
378.Pp
379.It Dv VIS_CONSDISPLAY
380Display data on the graphics device.
381The graphics driver is expected to display the data contained in the
382.Vt vis_display
383structure at the specified position on the console.
384.Pp
385The
386.Vt vis_display
387structure contains the following fields:
388.Bd -literal -offset 2n
389struct vis_display {
390    screen_pos_t   row;
391    screen_pos_t   col;
392    screen_size_t  width;
393    screen_size_t  height;
394    uchar_t        *data;
395    color_t        fg_color;
396    color_t        bg_color;
397};
398.Ed
399.Pp
400.Fa row
401and
402.Fa col
403specify at which starting row and column the date is to be displayed.
404If
405.Fa mode
406in the
407.Dv VIS_DEVINIT
408ioctl was set to
409.Dv VIS_TEXT ,
410.Fa row
411and
412.Fa col
413are defined to be a character offset
414from the starting position of the console device.
415If
416.Fa mode
417in the
418.Dv VIS_DEVINIT
419ioctl was set to
420.Dv VIS_PIXEL ,
421.Fa row
422and
423.Fa col
424are defined to be a pixel offset from the starting position of the console
425device.
426.Pp
427.Fa width
428and
429.Fa height
430specify the size of the
431.Fa data
432to be displayed.
433If
434.Fa mode
435in the
436.Dv VIS_DEVINIT
437ioctl was set to
438.Dv VIS_TEXT ,
439.Fa width
440and
441.Fa height
442define the size of
443.Fa data
444as rectangle that is
445.Fa width
446characters wide and
447.Fa height
448characters high.
449If
450.Fa mode
451in the
452.Dv VIS_DEVINIT
453ioctl was set to
454.Dv VIS_PIXEL ,
455.Fa width
456and
457.Fa height
458define the size of
459.Fa data
460as a rectangle that is
461.Fa width
462pixels wide and
463.Fa height
464pixels high.
465.Pp
466.Fa *data
467is a pointer to the data to be displayed on the console device.
468If
469.Fa mode
470in the
471.Dv VIS_DEVINIT
472ioctl was set to
473.Dv VIS_TEXT ,
474.Fa data
475is an array of
476.Sy ASCII
477characters to be displayed on the console device.
478The driver must break these characters up appropriately and display it in the
479rectangle defined by
480.Fa row ,
481.Fa col ,
482.Fa width ,
483and
484.Fa height .
485If
486.Fa mode
487in the
488.Dv VIS_DEVINIT
489ioctl was set to
490.Dv VIS_PIXEL ,
491.Fa data
492is an array of bitmap data to be displayed on the console device.
493The driver must break this data up appropriately and display it in the retangle
494defined by
495.Fa row ,
496.Fa col ,
497.Fa width ,
498and
499.Fa height .
500.Pp
501The
502.Fa fg_color
503and
504.Fa bg_color
505fields define the foreground and
506background color map indexes to use when displaying the data.
507.Fa fb_color
508is used for
509.Dq on
510pixels and
511.Fa bg_color
512is used for
513.Dq off
514pixels.
515.Pp
516.It Dv VIS_CONSCOPY
517Copy data from one location on the device to another.
518The driver is expected to copy the specified data.
519The source data should not be modified.
520Any modifications to the source data should be as a side effect of the copy
521destination overlapping the copy source.
522.Pp
523The argument is a pointer to a
524.Vt vis_copy
525structure which contains the following fields:
526.Bd -literal -offset 2n
527struct vis_copy {
528    screen_pos_t  s_row;
529    screen_pos_t  s_col;
530    screen_pos_t  e_row;
531    screen_pos_t  e_col;
532    screen_pos_t  t_row;
533    screen_pos_t  t_col;
534    short         direction;
535};
536.Ed
537.Pp
538.Fa s_row ,
539.Fa s_col ,
540.Fa e_row ,
541and
542.Fa e_col
543define the source rectangle of the copy.
544.Fa s_row
545and
546.Fa s_col
547are the upper left corner of the source rectangle.
548.Fa e_row
549and
550.Fa e_col
551are the lower right corner of the source rectangle.
552If
553.Fa mode
554in the
555.Dv VIS_DEVINIT
556.Fn ioctl
557was set to
558.Dv VIS_TEXT ,
559.Fa s_row ,
560.Fa s_col ,
561.Fa e_row ,
562and
563.Fa e_col
564are defined to be character offsets from the starting position of the console
565device.
566If
567.Fa mode
568in the
569.Dv VIS_DEVINIT
570.Fn ioctl
571was set to
572.Dv VIS_PIXEL ,
573.Fa s_row ,
574.Fa s_col ,
575.Fa e_row ,
576and
577.Fa e_col
578are
579defined to be pixel offsets from the starting position of the console device.
580.Pp
581.Fa t_row
582and
583.Fa t_col
584define the upper left corner of the destination rectangle of the copy.
585The entire rectangle is copied to this location.
586If
587.Fa mode
588in the
589.Dv VIS_DEVINIT
590ioctl was set to
591.Dv VIS_TEXT ,
592.Fa t_row ,
593and
594.Fa t_col
595are defined to be character offsets from the
596starting position of the console device.
597If
598.Fa mode
599in the
600.Dv VIS_DEVINIT
601ioctl was set to
602.Dv VIS_PIXEL ,
603.Fa t_row ,
604and
605.Fa t_col
606are defined to be pixel offsets from the starting position of the
607console device.
608.Pp
609.Fa direction
610specifies which way to do the copy.
611If direction is
612.Dv VIS_COPY_FORWARD
613the graphics driver should copy data from position
614.Po
615.Fa s_row ,
616.Fa s_col
617.Pc
618in the source rectangle to position
619.Po
620.Fa t_row ,
621.Fa t_col
622.Pc
623in the destination rectangle.
624If direction is
625.Dv VIS_COPY_BACKWARDS
626the graphics driver should copy data from position
627.Po
628.Fa e_row ,
629.Fa e_col
630.Pc
631in the source rectangle to position
632.Po
633.Fa t_row Ns + Ns
634.Po
635.Fa e_row Ns \- Ns
636.Fa s_row
637.Pc ,
638.Fa t_col Ns + Ns
639.Po
640.Fa e_col Ns \- Ns
641.Fa s_col
642.Pc
643.Pc
644in the destination rectangle.
645.El
646.Ss "Console Standalone Entry Points  (Polled I/O Interfaces)"
647Console standalone entry points are necessary only if the driver is
648implementing console-compatible extensions.
649All console vectored standalone
650entry points must be implemented along with all console-related ioctls if the
651console extension is implemented.
652.Bd -literal -offset 2n
653struct vis_polledio {
654    struct vis_polledio_arg *arg;
655    void    (*display)(vis_polledio_arg *, struct vis_consdisplay *);
656    void    (*copy)(vis_polledio_arg *, struct vis_conscopy *);
657    void    (*cursor)(vis_polledio_arg *, struct vis_conscursor *);
658};
659.Ed
660.Pp
661The
662.Vt vis_polledio
663structure is passed from the driver to the illumos
664operating environment, conveying the entry point addresses of three functions
665which perform the same operations of their similarly named ioctl counterparts.
666The rendering parameters for each entry point are derived from the same
667structure passed as the respective ioctl.
668See the
669.Sx "Console Optional Ioctls"
670section of this manpage for an explanation of the specific function each of the
671entry points,
672.Fn display ,
673.Fn copy ,
674and
675.Fn cursor
676are required to implement.
677In
678addition to performing the prescribed function of their ioctl counterparts, the
679standalone vectors operate in a special context and must adhere to a strict set
680of rules.
681The polled I/O vectors are called directly whenever the system is
682quiesced (running in a limited context) and must send output to the display.
683Standalone mode describes the state in which the system is running in
684single-threaded mode and only one processor is active.
685illumos operating
686environment services are stopped, along with all other threads on the system,
687prior to entering any of the polled I/O interfaces.
688The polled I/O vectors are
689called when the system is running in a standalone debugger, when executing the
690PROM monitor (OBP) or when panicking.
691.Pp
692The following restrictions must be observed in the polled I/O functions:
693.Bl -enum -offset indent
694.It
695The driver must not allocate memory.
696.It
697The driver must not wait on mutexes.
698.It
699The driver must not wait for interrupts.
700.It
701The driver must not call any DDI or LDI services.
702.It
703The driver must not call any system services.
704.El
705.Pp
706The system is single-threaded when calling these functions, meaning that all
707other threads are effectively halted.
708Single-threading makes mutexes (which
709cannot be held) easier to deal with, so long as the driver does not disturb any
710shared state.
711See
712.%T Writing Device Drivers
713for more information about implementing polled I/O entry points.
714.Sh SEE ALSO
715.Xr ioctl 2
716.Rs
717.%T Writing Device Drivers
718.Re
719.Sh NOTES
720On SPARC systems, compatible drivers supporting the kernel terminal emulator
721should export the
722.Sy tem-support
723DDI property.
724.Sy tem-support
725indicates that the driver supports the kernel terminal emulator.
726By exporting
727.Sy tem-support
728it's possible to avoid premature handling of an incompatible driver.
729.Bl -tag -width tem-support
730.It Sy tem-support
731This DDI property, set to 1, means driver is compatible with the console
732kernel framebuffer interface.
733.El
734