Skip Navigation Links | |
Exit Print View | |
Writing Device Drivers Oracle Solaris 11.1 Information Library |
Part I Designing Device Drivers for the Oracle Solaris Platform
1. Overview of Oracle Solaris Device Drivers
2. Oracle Solaris Kernel and Device Tree
5. Managing Events and Queueing Tasks
7. Device Access: Programmed I/O
10. Mapping Device and Kernel Memory
13. Hardening Oracle Solaris Drivers
14. Layered Driver Interface (LDI)
Part II Designing Specific Kinds of Device Drivers
15. Drivers for Character Devices
18. SCSI Host Bus Adapter Drivers
19. Drivers for Network Devices
Part III Building a Device Driver
22. Compiling, Loading, Packaging, and Testing Drivers
23. Debugging, Testing, and Tuning Device Drivers
24. Recommended Coding Practices
B. Summary of Oracle Solaris DDI/DKI Services
C. Making a Device Driver 64-Bit Ready
D. Console Frame Buffer Drivers
Oracle Solaris Consoles and the Kernel Terminal Emulator
x86 Platform Console Communication
SPARC Platform Console Communication
Video Mode Change Callback Interface
Implementing the Visual I/O Interfaces in Console Frame Buffer Drivers
Implementing Polled I/O in Console Frame Buffer Drivers
Frame Buffer Specific Configuration Module
Debugging a console frame buffer driver on an active system can be problematic.
Errors that are encountered in the early stages of booting the system do not generate a core dump.
Error or informative messages might not be displayed correctly on the screen.
USB keyboard input might fail.
This section offers some suggestions to help you develop, test, and debug console frame buffer drivers.
To test the ioctl commands, create additional ioctl entry points that are callable from a user application. Be sure to copy in the arguments appropriately. Use the ddi_copyin(9F) and ddi_copyout(9F) routines to transfer data to and from user address space. Then write an application to validate rendering, scrolling, and cursor behavior. This way, these ioctl commands do not affect your console while you develop and test the commands.
To ensure that the ioctl commands are working correctly, boot the system and log in. Check whether you get expected behavior when you execute commands such as prstat(1M), ls(1), vi(1), and man(1).
Execute the following script to validate that ANSI color is working correctly:
#!/bin/bash printf "\n\n\n\e[37;40m Color List \e[m\n\n" printf "\e[30m Color 30 black\e[m\n" printf "\e[31m Color 31 red\e[m\n" printf "\e[32m Color 32 green\e[m\n" printf "\e[33m Color 33 yellow\e[m\n" printf "\e[34m Color 34 blue\e[m\n" printf "\e[35m Color 35 purple\e[m\n" printf "\e[36m Color 36 cyan\e[m\n" printf "\e[37m Color 37 white\e[m\n\n" printf "\e[40m Backlight 40 black \e[m\n" printf "\e[41m Backlight 41 red \e[m\n" printf "\e[34;42m Backlight 42 green \e[m\n" printf "\e[43m Backlight 43 yellow\e[m\n" printf "\e[37;44m Backlight 44 blue \e[m\n" printf "\e[45m Backlight 45 purple\e[m\n" printf "\e[30;46m Backlight 46 cyan \e[m\n" printf "\e[30;47m Backlight 47 white \e[m\n\n"
The polled I/O interfaces are only available under the following circumstances:
When you enter the OpenBoot PROM by using the L1+A keystroke sequence
When you boot the system with a standalone debugger such as kmdb(1)
When the system panics
The polled I/O interfaces only become available at a certain point in the boot process. Polled I/O requests issued from the OpenBoot PROM before the system is running are not rendered. Similarly, kmdb prompts issued before the console is configured are not rendered.
To test the polled I/O interfaces, enter the OpenBoot PROM by using the L1+A keystroke sequence. To validate that the polled I/O interfaces are being used, type the following command at the OpenBoot PROM ok prompt:
ok 1b emit ." [32m This is a test" 1b emit ." [m"
The polled I/O interfaces are working properly if the following statements are true:
The result of the above command is that the phrase This is a test is displayed in green.
The OpenBoot PROM continues to function correctly.
Scrolling performs as expected.
The cursor displays correctly.
The system can be reentered and continued repeatedly.
To determine whether the video mode change callback function is working properly, log in to the system and use fbconfig(1M) to change the resolution and depth of the frame buffer several times. If the console continues to display text properly, the video mode change callback function is working correctly. The kernel terminal emulator might adjust the font size to accommodate different screen sizes, but that is not significant to the console frame buffer driver.
To determine whether the X Window System and the console frame buffer driver interact correctly, switch between the X Window System and the command line several times while modifying the X Window System's video resolution and the command line resolution in different ways. If the X Window System exits and the console characters are not displayed correctly, either the X Window System did not notify the driver console code that the video mode changed or the driver did not call the kernel terminal emulator's video mode change callback function.
During boot, the system sends messages to /var/adm/messages if the system fails to locate or successfully load a kernel terminal emulator compatible frame buffer driver. To monitor these messages, type the following command in a separate window:
% tail -f /var/adm/messages
To avoid problems with USB while debugging the driver, change the EEPROM input-device NVRAM configuration parameter to use a serial port instead of the keyboard. See the eeprom(1M) man page for more information about this parameter.