Re: [Linux-fbdev-devel] The future of framebuffer

[Nick K. <nic...@ma...>]

Hello, Sven!
On Fri, 5 Oct 2001 10:16:36 +0200, you wrote:

> On Thu, Oct 04, 2001 at 09:29:18PM +0400, Nick Kurshev wrote:
> > Hello, Sven!
> > > >  > does anyone know where I can find the program 'cpi2fnt' referenced in
> > > >  > linux/drivers/video/font_8x16.c?
> > > >  
> > > >  `cpi2fnt' is a very old AmigaOS program.
> > > >  
> > > >  Greetings,
> > > >  
> > > >  Geert
> > > > 
> > > > So it seems that it's still big problem ;)
> > > 
> > > Sure, you could look at it, you still need to have access to the cpi files
> > > though.
> > > 
> > Only once to get linux compatible fonts. Anyway exist people who has dos.cpi files
> > and can do that.
> 
> Well, but what is the licensing of those files ?
> 
> Do we have a legal right to use them without someone claiming copyrigth and
> suing us over them ?
> 
IMHO - these files were purchased, and their owners have rights to convert them
to any form. As extremal case - I'm able to make it by hand but it's stupid work
and currently linux has no fbdev-NLS to accept them.

> > > Err, because the drivers were loaded in the kernel and were run unprotected at
> > > CPL 0 or whatever you call it. It may be not the case with NVIdia, but try
> > > running older drivers for older video cards with a newer NT kernel or vice
> > > versa.
> > > 
> > It's so understandable that I can't use nt4.0 drivers for 2000 same as linux-2.2 drivers
> > for linux-2.4 but I never told about such usage.
> 
> Well, certain 2.4 drivers were backported for 2.2, and most 2.2 drivers still
> work for 2.4 kernels.
> 
> Look at Romain Dolbeau's pm3fb drivers, there is only one source for both
> 2.2.x and 2.4.x kernels.
> 
Do you mean a character devices?:

#if LINUX_VERSION_CODE >= 0x020400
static struct file_operations xxx_fops =
{
	llseek:		xxx_lseek,
	read:		xxx_read,
	write:		xxx_write,
	ioctl:		xxx_ioctl,
	mmap:		xxx_mmap,
	open:		xxx_open,
	release: 	xxx_release
};
#else
static struct file_operations xxx_fops =
{
	xxx_lseek,
	xxx_read,
	xxx_write,
	NULL,
	NULL,
	xxx_ioctl,
	xxx_mmap,
	xxx_open,
	NULL,
	xxx_release
};
#endif

> > > This is typically the problem whcih are avoided by running the exact same
> > > version of linux and its drivers, built with the same compiler and same
> > > binutils.
> > > 
> > But it is justly for any opensource drivers even if they are 3-rd party ones.
> 
> No, you will get the kernel, build with redhat's broken gcc or whatever they
> released with version M.m, and build the modules with the currently fixed
> incompatible gcc.
> 
IMHO you mean binary form but I mean source form. gcc version don't matter in this case.

> Only problems will come of it.
> 
Let users use suggested gcc - and no problems.

> > > > Anyway - it would be better to move drivers like fbdev, audio and other out from kernel.
> > > 
> > > And to where ? 
> > > 
> > > and for what real gain ?
> > > 
> > Simply because I need only one audio driver but not full collection for every audio card.
> 
> Just build yourself a custom kernel config, and after unpacking a new kernel,
> run make oldconfig on it, and build your kernel.
> 
> If you worry about additional patches, debian kernel-package program together
> with an appropriate kernel-patch package will build the kernel for you without
> problem. It will even build a nice debian package containing it.
> 
> > >From other side - kernel don't require them for normal working but they will enlarge kernel
> > sources up to infinity in the nearest future. (It's impossible to have support for
> > any hardware in one package)
> 
> Well, why not, linux kernel is many many times smaller than NTs code.
> 
But I never download NT through my modem as Linux.

> > > You can already build most of them as modules, isn't that what you want ?
> > > 
> > > > But kernel should have mechanism to handle the 3rd party drivers.
> > > 
> > > Well, i suppose you mean closed source i386 only commercial 3rd party drivers.
> > > No, you will not get much support about these kind of stuff.
> > > 
> > There exist many firms which don't want to open sources or documenation on their hardware
> 
> Just boycott them, ...
> 
It's possible for HomePC only.

> Unless they release drivers for all arches supported by linux, and not just
> only i386.
> 
> Also you can have no guarantee that a bug is not present, and if found that it
> may be closed some day.
> 
> Closed source drivers are _BAD_, it should not be encouraged.
> 
But they are better than nothing.

> > simply because it will give possibility to avoid some hardware features (like copy protection
> > mechanism of tv-out chips and so on) but as result linux world have no support for such hardware
> > or its parts.
> 
> There is no way copy protectioncan be implemented in hardware, there are even
> closed source windows program that allow you to patch the corresponding
> windows code to extract the DVD data while visualising.
> 
But it is illegal and privacy software.
Anyway such programs can't be by legal stuff.

> Anyway, if i buy a DVD or a CD, i expect to be able to use it, in any way that
> it pleases me, and we already pay a tax on blank videos tapes, tapes or even
> CDRs, so ...
> 
Agree. But when you buy DVD you meet these problems everywhere.
If someone have purchase DVD in America then why he can't use it in Europe?
Since DVD has too many limitations of its usage may be we should to boycott them too? ;)

> > > > As for me - I already tired to reinstall alsa and lm_sensor drivers after each kernel updating.
> > > 
> > > Mmm, aren't alsa in the kernel ? And what does it really offer more than the
> > > standard kernel sound drivers ?
> > > 
> > Alsa it's disputable sample but lm_sensors offer really inuque features which currently
> > don't exist in the kernel.
> 
> And do you know why that is ? What is the reason for it not being accepted by
> linus ? If you really feel like it, you could look at it, fix anything that
> needs fixing, and have that functionality included in the official kernel.
> 
AFAIK - Linus has around 100-500 patches avery single day.
Do you guess that he is able to process every of them?
From other point - if Linus has XXX hardware but have received patch (or driver)
for YYY hardware then how he can be sure that accepted patch is workable?
He can do that only from compilation point.

> > > Remember, what is in the stable kernels is considered as stable, you have no
> > > such guarantee about random third parties drivers.
> > > 
> > What I'm losing if I'll get broken sensor driver? IMHO - nothing.
> > (It's truth for fbdev on x86 platforms)
> 
> Well, apart from possible random bad code. If it is not in the official
> kernel, then it can only be that nobody cares enough about it, or that the big
> guys (linus and co) feel that there is a problem with it, be it techincal or
> licence. In any way, i would have more confidence in them than in any third
> party driver writer.
> 
From hipotetical point - if I get broken driver of file system then it will be tragedy
personally for me.
But for what Linux should has these unsignificand from stability point drivers (audio, fbdev, sensors)?
IMHO they are unnecessary pressing on kernel and on its author. Moving such drivers
from kernel only will give possibility to build more qualitative Linux and attract
much more people for building Linux infrastructure.

> Friendly,
> 
> Sven Luther
> 


Best regards! Nick