Re: vgacon fixes to help font restauration in X11
Alan Cox writes: > On Llu, 2005-01-17 at 14:29, Egbert Eich wrote: > > OK, sounds promising. The changed Xserver pieces are in HEAD of the > > X.Org tree. I'll see that I make the necessary adjustments to have > > a soft detection if you can give me a version number of the kernel > > which will have the new features. > > Send a copy directly to [EMAIL PROTECTED] and [EMAIL PROTECTED] for merging. > It looks fine to me. You'll need to include a "Signed-off-by: .." line > to indicate you are submitting it and have the rights to do so. You can > tag it with "Approved-by: Alan Cox <[EMAIL PROTECTED]>". Thanks, I will do that. I have attached the patch for kernel version detection to the freedesktop.org bugzilla (#2277) assuming this feature will be in the kernel starting with version 2.6.11. > > If you mention you need to know what kernel merges it for the X11 check > I'm sure you'll get an answer. > OK, will do. Thanks! Egbert. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vgacon fixes to help font restauration in X11
Alan Cox writes: On Llu, 2005-01-17 at 14:29, Egbert Eich wrote: OK, sounds promising. The changed Xserver pieces are in HEAD of the X.Org tree. I'll see that I make the necessary adjustments to have a soft detection if you can give me a version number of the kernel which will have the new features. Send a copy directly to [EMAIL PROTECTED] and [EMAIL PROTECTED] for merging. It looks fine to me. You'll need to include a Signed-off-by: .. line to indicate you are submitting it and have the rights to do so. You can tag it with Approved-by: Alan Cox [EMAIL PROTECTED]. Thanks, I will do that. I have attached the patch for kernel version detection to the freedesktop.org bugzilla (#2277) assuming this feature will be in the kernel starting with version 2.6.11. If you mention you need to know what kernel merges it for the X11 check I'm sure you'll get an answer. OK, will do. Thanks! Egbert. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vgacon fixes to help font restauration in X11
On Llu, 2005-01-17 at 14:29, Egbert Eich wrote: > OK, sounds promising. The changed Xserver pieces are in HEAD of the > X.Org tree. I'll see that I make the necessary adjustments to have > a soft detection if you can give me a version number of the kernel > which will have the new features. Send a copy directly to [EMAIL PROTECTED] and [EMAIL PROTECTED] for merging. It looks fine to me. You'll need to include a "Signed-off-by: .." line to indicate you are submitting it and have the rights to do so. You can tag it with "Approved-by: Alan Cox <[EMAIL PROTECTED]>". If you mention you need to know what kernel merges it for the X11 check I'm sure you'll get an answer. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vgacon fixes to help font restauration in X11
Alan Cox writes: > On Llu, 2005-01-17 at 09:07, Egbert Eich wrote: > > Can you point me to these reports? > > I tested with a couple chipsets here and didn't find any problems. > > I'll take a dig. The ones I've got are for 2.4 so relate to old code. > > > We could check for the kernel version. This could be done during build > > time - assuming we don't ship generic binaries or during run time if we > > want to provide binaries that work everywhere. > > In reality the former would be sufficient for a lot of cases - especially > > for vendor supplied binaries. > > The former would be a disaster for Fedora for example - we ship > 'current' kernels and having kernel upgrades require a new X11 won't > endear users . A runtime check on version might work I was wondering if No, it would rather be the other way around. A new version of X would require a certain version of the kernel - unless you plan to drop the feature again. This however will not be necessary until 6.9/7 (however it will be named) comes out. I can implement both ways. Since the new font code lives in the OS dependent part this should not be a problem at all. The only disadvantage may be that I may not be able to turn off the old font code in the generic vgaHW stuff. > it would be better to have an actual interface that said "do/do not > restore the extra bits in kernel". > > That also avoids any suprises and regressions ? I used to have a patch like that. But kernel people I've talked to told me that it would be preferrable not to change the API if not necessary. In my opinion it is not. The changes only affect cases where a new font gets written or restored. > > Anyway, would my patch be acceptable for the kernel? > > I'm not video maintainer but other than the detection question it looks > sensible to me. > OK, sounds promising. The changed Xserver pieces are in HEAD of the X.Org tree. I'll see that I make the necessary adjustments to have a soft detection if you can give me a version number of the kernel which will have the new features. Egbert. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vgacon fixes to help font restauration in X11
On Llu, 2005-01-17 at 09:07, Egbert Eich wrote: > Can you point me to these reports? > I tested with a couple chipsets here and didn't find any problems. I'll take a dig. The ones I've got are for 2.4 so relate to old code. > We could check for the kernel version. This could be done during build > time - assuming we don't ship generic binaries or during run time if we > want to provide binaries that work everywhere. > In reality the former would be sufficient for a lot of cases - especially > for vendor supplied binaries. The former would be a disaster for Fedora for example - we ship 'current' kernels and having kernel upgrades require a new X11 won't endear users . A runtime check on version might work I was wondering if it would be better to have an actual interface that said "do/do not restore the extra bits in kernel". That also avoids any suprises and regressions ? > Anyway, would my patch be acceptable for the kernel? I'm not video maintainer but other than the detection question it looks sensible to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vgacon fixes to help font restauration in X11
[Please leave me in Cc: as I'm not subscribed to this list] Alan Cox writes: > On Maw, 2005-01-11 at 14:28, Egbert Eich wrote: > > I'm fully aware that in the long run we will need to look into a new > > driver model for graphics where no two instances fight over who gets > > register access. However such a model won't be created nor will we get > > the majority of the drivers ported over night. > > Therefore we need to find an interim solution for the most pressing > > problems. > > This doesn't appear to work as a solution because the functionality > changes won't be in all the existing kernel, and also because the kernel > font save has a couple of bugs reported against it with regards to > saving the right data that might need looking at anyway. Can you point me to these reports? I tested with a couple chipsets here and didn't find any problems. Maybe we can compare the code in X with the code in the kernel for the amount of data to save. However we don't know if the X font code is completely without problems. I remeber fixing a problem in X years ago - a case where the kernel got it right ;-) X VGA font code involves a lot of magic. Also things might differ slightly form HW vendor to vendor and it will be extremely hard to get it right for all chipset models therefore I would not even talk about 'bugs' ;-) > > It seems it would be neccessary for X to have a way to know whether the > feature is present. > We could check for the kernel version. This could be done during build time - assuming we don't ship generic binaries or during run time if we want to provide binaries that work everywhere. In reality the former would be sufficient for a lot of cases - especially for vendor supplied binaries. Once X.Org starts shipping binaries it should definitely provide a version that fits everywhere. But maybe you have a better suggestion. Anyway, would my patch be acceptable for the kernel? Cheers, Egbert. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vgacon fixes to help font restauration in X11
[Please leave me in Cc: as I'm not subscribed to this list] Alan Cox writes: On Maw, 2005-01-11 at 14:28, Egbert Eich wrote: I'm fully aware that in the long run we will need to look into a new driver model for graphics where no two instances fight over who gets register access. However such a model won't be created nor will we get the majority of the drivers ported over night. Therefore we need to find an interim solution for the most pressing problems. This doesn't appear to work as a solution because the functionality changes won't be in all the existing kernel, and also because the kernel font save has a couple of bugs reported against it with regards to saving the right data that might need looking at anyway. Can you point me to these reports? I tested with a couple chipsets here and didn't find any problems. Maybe we can compare the code in X with the code in the kernel for the amount of data to save. However we don't know if the X font code is completely without problems. I remeber fixing a problem in X years ago - a case where the kernel got it right ;-) X VGA font code involves a lot of magic. Also things might differ slightly form HW vendor to vendor and it will be extremely hard to get it right for all chipset models therefore I would not even talk about 'bugs' ;-) It seems it would be neccessary for X to have a way to know whether the feature is present. We could check for the kernel version. This could be done during build time - assuming we don't ship generic binaries or during run time if we want to provide binaries that work everywhere. In reality the former would be sufficient for a lot of cases - especially for vendor supplied binaries. Once X.Org starts shipping binaries it should definitely provide a version that fits everywhere. But maybe you have a better suggestion. Anyway, would my patch be acceptable for the kernel? Cheers, Egbert. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vgacon fixes to help font restauration in X11
On Llu, 2005-01-17 at 09:07, Egbert Eich wrote: Can you point me to these reports? I tested with a couple chipsets here and didn't find any problems. I'll take a dig. The ones I've got are for 2.4 so relate to old code. We could check for the kernel version. This could be done during build time - assuming we don't ship generic binaries or during run time if we want to provide binaries that work everywhere. In reality the former would be sufficient for a lot of cases - especially for vendor supplied binaries. The former would be a disaster for Fedora for example - we ship 'current' kernels and having kernel upgrades require a new X11 won't endear users . A runtime check on version might work I was wondering if it would be better to have an actual interface that said do/do not restore the extra bits in kernel. That also avoids any suprises and regressions ? Anyway, would my patch be acceptable for the kernel? I'm not video maintainer but other than the detection question it looks sensible to me. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vgacon fixes to help font restauration in X11
Alan Cox writes: On Llu, 2005-01-17 at 09:07, Egbert Eich wrote: Can you point me to these reports? I tested with a couple chipsets here and didn't find any problems. I'll take a dig. The ones I've got are for 2.4 so relate to old code. We could check for the kernel version. This could be done during build time - assuming we don't ship generic binaries or during run time if we want to provide binaries that work everywhere. In reality the former would be sufficient for a lot of cases - especially for vendor supplied binaries. The former would be a disaster for Fedora for example - we ship 'current' kernels and having kernel upgrades require a new X11 won't endear users . A runtime check on version might work I was wondering if No, it would rather be the other way around. A new version of X would require a certain version of the kernel - unless you plan to drop the feature again. This however will not be necessary until 6.9/7 (however it will be named) comes out. I can implement both ways. Since the new font code lives in the OS dependent part this should not be a problem at all. The only disadvantage may be that I may not be able to turn off the old font code in the generic vgaHW stuff. it would be better to have an actual interface that said do/do not restore the extra bits in kernel. That also avoids any suprises and regressions ? I used to have a patch like that. But kernel people I've talked to told me that it would be preferrable not to change the API if not necessary. In my opinion it is not. The changes only affect cases where a new font gets written or restored. Anyway, would my patch be acceptable for the kernel? I'm not video maintainer but other than the detection question it looks sensible to me. OK, sounds promising. The changed Xserver pieces are in HEAD of the X.Org tree. I'll see that I make the necessary adjustments to have a soft detection if you can give me a version number of the kernel which will have the new features. Egbert. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vgacon fixes to help font restauration in X11
On Llu, 2005-01-17 at 14:29, Egbert Eich wrote: OK, sounds promising. The changed Xserver pieces are in HEAD of the X.Org tree. I'll see that I make the necessary adjustments to have a soft detection if you can give me a version number of the kernel which will have the new features. Send a copy directly to [EMAIL PROTECTED] and [EMAIL PROTECTED] for merging. It looks fine to me. You'll need to include a Signed-off-by: .. line to indicate you are submitting it and have the rights to do so. You can tag it with Approved-by: Alan Cox [EMAIL PROTECTED]. If you mention you need to know what kernel merges it for the X11 check I'm sure you'll get an answer. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
