And a question: how do you imagine native mode selection for several connectors? Select the "smallest" mode? Or just support one connector, i.e. break enumeration loop if we find the first connector. Nevertheless, properly support several displays is hardly
Like you say, properly supporting several displays is hard (especially with the limitations of VESA BIOS). Thus any reasonable well-documented behaviour is OK for me.
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.
Wait... Now I'm unsure if we are speaking about the same code, because: 1. I don't access the data structure in sys_debug_console(), I just pass the pointer further. 2. I do use copy_from_uspace() when I access the data structure, see kernel/genarch/src/fb/fb.c:644
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().
Well. Am I right: it should be a top-level "driver", e.g. named x86fb, which will just try at first start vesafb, and if it fail, kfb?
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.
I acknowledge that the documentation of this mechanism is not easy to find. But this is exactly the reason why I always try to push you to report your plans -- what and how do you want to tackle next. Since you don't do it, I can only inform you about your suboptimal solutions afterwards. This should be a lesson for you.
You also asked me to make compositor to support viewports "hotplugging", to solve "timing problem": when compositor starts earlier then driver. But. I can't find PnP-framework in HelenOS
The DDF does the hot-plugging. As soon as a new device is discovered and a suitable driver for the device is found, it is started.
I don't see other ways to support "hotplugging". Busyloop in compositor?
No. The location service provides a notification mechanism that will notify the compositor about new viewports. More precisely, it will inform the compositor about a new visualizer driver registered and trigger new viewport discovery.
The code should be already in place, see categery_change_cb() and the loc_register_cat_change_cb(category_change_cb) call in compositor.c.
I am not sure whether this code path has been already tested and debugged, but it should work in principle (the same notification mechanism works elsewhere). Thus it shouldn't be so hard to make it work.
Since there is no access flags in parea_t structure, you want me to implement them?!
Yes, I would like you to implement it, because it will make the code a bit more elegant and that is always our goal. Do you have a problem with that?
Having said that, from the entire list of action items from my previous email, this one definitively falls into the "would be nice to have" category, not "a necessary requirement". Thus please prioritize accordingly.
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
