Sorry. It seems I've sent empty email. > The default behaviour can be the smallest common mode. You can also have > symbolic arguments for compctl that would select the smallest common > mode or the largest mode supported by at least one output.
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. 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. It was just design note. > Oh, I see, I have missed that. Sorry. However, the usual convention is > that only the syscall wrapper touches the user space pointers and calls > copy_from_uspace(). All the other kernel functions should already expect > kernel pointers. > > Anyway, the fb_set_mode() function might be possibly called from other > kernel code and then you would have hard time calling copy_from_uspace(). I belive I should describe why I use 2 parameters: output device kind and pointer to data. I've thought that somebody in the future will implement mode setting for e.g. text console (to have something like 90x60 or 132x43 mode. It's possible to do now with libvbe, if card provides VESA text modes) and will want to inform kernel console about new mode, using text console kind number and text console struct, which may differ from framebuffer console struct. Thats why I call copy_from_uspace() only from fb_set_mode(), when it makes sure that data is sent for it in right format. 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. > No. The vesafb driver should be a more specific driver, indicated by a > higher priority value in vesafb.ma (say 100) using some common specifier > (e.g. "100 x86fb"). Thus, the DDF (Device Driver Framework) will try to > initialize the vesafb driver first. > > If the vesafb initialization fails (for any reason), the DDF will go on > looking for any other (less specific) suitable driver. Thus by having a > line say "10 x86fb" in kfb.ma, the kfb driver will be used as a fall-back. Well, should be binary file named x86fb then? And what to do with record in kfb.ma on non-x86 arches? _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
