2014-08-12 0:17 GMT+04:00, Martin Decky <[email protected]>: >> 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 >
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
