> - The vesafb driver does not set the optimal mode (according to EDID) > yet, it only reuses the kfb mode.
Just yet. 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 > * In sys_debug_console() (kernel/generic/src/console.c) you access the > data structure supplied from user space without any checks. The > approach is not only vulnerable, moreover it works only on x86 by > sheer coincidence. > > AI: Use copy_from_uspace() to access the user space supplied > structure. 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 Or you ment that there are architectrures where the pointer, passed in syscall parameters, should be somehow preprocessed before sending it to other functions? > AI: I still don't like how the kfb and vesafb "coexist". Your > solution requires that kfb is completely absent from the system on > ia32 and amd64. But the original suggestion was a bit different [3]. > It would be nice if both kfb and vesafb could coexist in the system. 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? 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, where I can write script to e.g. call "compctl comp:0/ctl discover-viewports" on visualizer appearance. I don't see other ways to support "hotplugging". Busyloop in compositor? Acknowledge compositor from driver? Doesn't look like a "nice proper solution". Could you advice any not-hackish solution? > AI: If I am not mistaken, the real-mode IVT area does not necessarily > need to be mappable in a read/write mode. It would be nice if the DDI > would only allow to map it in a read-only mode. Since there is no access flags in parea_t structure, you want me to implement them?! _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
