Video driver
RE:Video driver (another question)
First, thank you for your response!
But sorry, I never imagine that the 'device manager' were as dificult module.
I am trying to determinate which 'entry points' my device driver must have,
but seems to be imposible to select a list of entry points that can be used for every devices.
I know that I just must transmit data between the devices and memory, but...
Into which entry point I must put services like:
- Move text video cursor
- Get the current position cursor
- Clean the screen
- Turn on/off disquete drive motor
- Control volume of a sound card
And how must be handle diferences like position, e.g. Video driver needs a coordinate (x,y), but floppy drives needs a head-cylinder-sector.
If someone know about some link or book abuot this subjet,
I appreciate let me know.
Thank you again,
pepito
But sorry, I never imagine that the 'device manager' were as dificult module.
I am trying to determinate which 'entry points' my device driver must have,
but seems to be imposible to select a list of entry points that can be used for every devices.
I know that I just must transmit data between the devices and memory, but...
Into which entry point I must put services like:
- Move text video cursor
- Get the current position cursor
- Clean the screen
- Turn on/off disquete drive motor
- Control volume of a sound card
And how must be handle diferences like position, e.g. Video driver needs a coordinate (x,y), but floppy drives needs a head-cylinder-sector.
If someone know about some link or book abuot this subjet,
I appreciate let me know.
Thank you again,
pepito
RE:Video driver (another question)
For every type of device(memory storage, video image, hdd, mouse, keyboard, ...) has it's own interface-you can't have the same set of entry points for all the devices, cause then what will be the diff between them? The differences between devices is followed by the difference in there interfaces-you can't use a video screen as a hdd.
Anton
Anton
RE:Video driver (another question)
pepito,
Hey a console is a character device how ever video and network interfaces are under their own categories usually.
If you are playing with character devices as you referenced floppy drive you are never really going to specify the CHS or with a console the X,Y you just seek into the device it is like a big mem area so if you wanted sector 4 you just seek 512*4 into the device with your screen you would seek row*col position in.
-Christopher
Hey a console is a character device how ever video and network interfaces are under their own categories usually.
If you are playing with character devices as you referenced floppy drive you are never really going to specify the CHS or with a console the X,Y you just seek into the device it is like a big mem area so if you wanted sector 4 you just seek 512*4 into the device with your screen you would seek row*col position in.
-Christopher
RE:Video driver
On the lowest level, all video devices will probably look like block devices
However, that's not much use by itself, so you'll probably want to wrap it with higher-level interfaces. The console will most definitely have a character device on top of it that does the normal stuff you'd expect from a console.
Gnome.
However, that's not much use by itself, so you'll probably want to wrap it with higher-level interfaces. The console will most definitely have a character device on top of it that does the normal stuff you'd expect from a console.
Gnome.
RE:Video driver (another question)
Christopher:
You say:
"If you are playing with character devices as you referenced floppy drive you are never really going to specify the CHS or with a console the X,Y you just seek into the device it is like a big mem area so if you wanted sector 4 you just seek 512*4 into the device with your screen you would seek row*col position in."
That's means that the device driver mus calculate the position?
pepito
You say:
"If you are playing with character devices as you referenced floppy drive you are never really going to specify the CHS or with a console the X,Y you just seek into the device it is like a big mem area so if you wanted sector 4 you just seek 512*4 into the device with your screen you would seek row*col position in."
That's means that the device driver mus calculate the position?
pepito
RE:Video driver (another question)
pepito,
Yes normally you will pass an offset into the driver the driver will figure out what to do with it if you pass x*y into your frame buffer it will find the right byte. If you pass sector offset z into a drive driver it will figure out what to do with it.
-Christopher
Yes normally you will pass an offset into the driver the driver will figure out what to do with it if you pass x*y into your frame buffer it will find the right byte. If you pass sector offset z into a drive driver it will figure out what to do with it.
-Christopher
RE:Video driver
Oh yes, moving the cursor, changing colors, etc... It's all done with special character sequences passed to the console driver (at least in UNIXes). If you do it like this, you won't need to use a different console driver interface.
RE:Video driver (another question)
If you're going to have a driver interface similar to Unix (or any file system centric driver system) you can have a somewhat similar driver interface, albeit a very simple and vague one:
Each driver implements the following:
open
close
read
write
ioctl
The ioctl function has a common prototype but, of course, its implemention is driver specific, and will contain different operations depending on which driver it is being written for.
It is entirely true, however, that you can't really have a common interface for all drivers. It would be nice, and make things much more simple, and easy, but the hardware is just too different to make this practical. I suspect if anyone could ever find an API that was abstract enough to support all forms of hardware, that it would be much too abstracted to be useful.
Cheers,
Jeff
Each driver implements the following:
open
close
read
write
ioctl
The ioctl function has a common prototype but, of course, its implemention is driver specific, and will contain different operations depending on which driver it is being written for.
It is entirely true, however, that you can't really have a common interface for all drivers. It would be nice, and make things much more simple, and easy, but the hardware is just too different to make this practical. I suspect if anyone could ever find an API that was abstract enough to support all forms of hardware, that it would be much too abstracted to be useful.
Cheers,
Jeff