On Sun, Nov 28, 2010 at 9:29 AM, Microcai <microcai@xxxxxxxxxxxxxxxxx> wrote: > å 2010-11-28æç 09:05 -0500ïjonsmirl@xxxxxxxxxåéï >> On Sun, Nov 28, 2010 at 8:42 AM, Microcai <microcai@xxxxxxxxxxxxxxxxx> wrote: >> > å 2010-11-28æç 08:24 -0500ïTheodore Tsoåéï >> >> On Nov 28, 2010, at 5:57 AM, Microcai wrote: >> >> >> >> > Hi, there >> >> > >> >> > Â Â I'm implementing the UNICODE font of the framebuffer console, (see >> >> > http://lkml.org/lkml/2010/11/26/50 in case you do not got my email). But >> >> > current vt code is too bugy, too many direct assumes about vt buffer, >> >> > This makes me so hard to hack. ÂThere is TODO telling me to add UNICODE >> >> > support, but no room for such code, that's why my patch is so tricky. >> >> > >> >> > Â Â And the code itself, if you'll excuse me, it isn't as beautiful as rest >> >> > of the kernel. >> >> > Â Â So, it really really need a clean rewrite.I'm ganna take is hard job. >> >> > Â Â And, please tell me if is worth to do so. >> >> >> >> Yes, the console is code is very old. Â But please be aware that lots of code (both in the kernel and in userspace) has dependencies upon how the code behaves. Â So changing it in a way that does not break backwards compatibility is hard. Âi.e., it is hard to hack for a reason. >> >> >> >> I would recommend an incremental rewrite (i.e., one patch at a time), as opposed to a rewrite from scratch. Â Because people will want to be assured that things haven't broken in a horrible way as a result of a complete rewrite... >> >> >> >> -- Ted >> >> >> > >> > Yeah, I'd also like to rewrite it incrementally. But... who will accept >> > that incrementally patch ? It just seems that incremental patch will be >> > horrible at the beginning...... It will be discard without a >> > reason ..... >> >> You can use CONFIG_VT to remove the entire VT subsystem. It might be >> easier for you to write an alternative VT system that could be enabled >> with a different flag. >> >> The VT system is very old code from the earliest days of Linux. >> Thousands of things depend on it both in the kernel and user space. It >> will be very hard to make significant changes to it that don't break >> lots of dependent code. >> >> Another model to consider... Remove the VT subsystem. Replace it will >> a Unicode VT system built in user space. Using the existing kernel >> code, leave a single user console in the kernel that would only be >> used for system maintenance. Normal users would never see this console >> unless their system was really messed up. >> >> > > So, here is the design according to your description Â.. > > JUST export /dev/fb and /dev/pts and /dev/console > The kernel use /dev/console, but invisible. > The rest of the world uses /dev/pts > > Make init using /dev/fb to display boot message, and agetty runs > on /dev/pts > > Another user-space program use /dev/fb to display all /dev/pts , you can > use alt+Fx to switch between them (kernel no longer handles console > switch). > > So, there is no virtual console ... . Just as windows Â(who uses cmd.exe > to display console ) > > kernel just deal with BYTE stream, no need for font handling ..... > > Will you agree with that kind of system ? It is a lot of work to get a system like that running, but it should work when finished. It also lets you avoid messing with the VT layer which will be a very painful process. Now that we have KMS you can even hide the boot display if you want. My Ubuntu system jumps straight to a graphical boot display and you have to hit a key to see the boot console. > > > > > > -- Jon Smirl jonsmirl@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-console" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
