A note about modes. I was implementing mode list intersection if there
is several controllers. I've just hardcoded EDID data from my
notebook, in addition to qemu's EDID. And found out that intersection
is empty. I've compared not only resolution, but other parameters such
as htotal etc. My notebook's screen provides very strange native mode:
it very similar to CVT 1440x900 60 Hz reduced blanking except two
things: 1440x900RB has positive hsync, but my monitor reports negative
hsync and 1440x900RB has 1600 total horisontal pixels, but my monitor
provides 1900-with-something htotal, which looks VERY strange. qemu
reports standard 1440x900, so there is no similar modes, if we compare
them strictly.
Yes, I believe that strict comparison won't work here. If there is a
strict match, then great, but you should definitively be able to ignore
differences in the hsync/vsync polarity, total number of pixels, etc.
There is also the list of VESA-defined standard modes with timings [1]
that you should also consider. They are probably better as a baseline
than those from your laptop.
[1]
ftp://ftp.cis.nctu.edu.tw/pub/csie/Software/X11/private/VeSaSpEcS/VESA_Document_Center_Monitor_Interface/DMTv1r11.pdf
Oh, well. What am I speaking about? I plan to weak "similarity test",
only compare visible area, then I hope we can expect anything in
intersection.
Yes, good idea.
Well, if it can be called from kernel code. Then, I think, mode
parameters structure should be unified, copied from user space in
sys_debug_console and driver will use this parameters if it'll its
kind number.
Yes, that is the right approach. The arguments from user space should be
checked and converted from the user address space to the kernel address
space in the syscall handler (sys_debug_console). All other kernel
functions should already work with arguments that are valid in the
kernel address space.
The syscall handlers define a barrier and interface between the kernel
and the user space. This barrier should be concentrated in one
well-defined place (the syscall handlers), not spread over the whole kernel.
Well, should be binary file named x86fb then? And what to do with
record in kfb.ma on non-x86 arches?
No! Do NOT rename the binaries, I am not talking about the names of the
binaries. I am only talking about the contents of the *.ma files.
The identifier x86fb is perhaps not the most fitting. The idea is to use
something that logically covers both VESA and the kernel framebuffer --
maybe just "fb". I suggest the *.ma files might look as follows:
==== vesafb.ma ====
100 virtual&fb
==== end of vesafb.ma ====
==== kfb.ma ====
10 virtual&fb
==== end of kfb.ma ====
This means that you don't have to define a new identifier in rootpc
(only rename the identifier in rootvirt), vesafb will take precedence
over kfb, but kfb will still be used if vesafb is not present.
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
