On Thu, Jan 13, 2011 at 12:03 PM, Gordan Bobic gordan@bobich.net wrote:
Replying off list since you did the same.
Peter Robinson wrote:
On Thu, Jan 13, 2011 at 11:38 AM, Gordan Bobic gordan@bobich.net wrote:
Peter Robinson wrote:
On Thu, Jan 13, 2011 at 10:22 AM, Gordan Bobic gordan@bobich.net wrote:
I have a question on policies of how and whether Fedora-ARM patches are rolled back into rawhide. The reason I ask is because I see overlap between the required ARM specific patches between F11 and F12. What is the policy for rolling these patches back into upstream and (more importantly in case upstream is slow/reluctant to accept them) rawhide?
In a lot of cases the people dealing with the issues have the ability to commit the fixes themselves so as to be able to push them directly upstream where necessary.
Is there a formal procedure for that? My concern is that this process doesn't seem to work out in a timely and positive fashion in a significant number of cases (otherwise we wouldn't have that big a required patch overlap between Fedora releases on ARM).
Not particularly, it depends on the package. In some cases its a simple spec fix, in other cases there's issues with the compilation of the code on non x86 architectures. F-11 and F-12 is also EOL and in a lot of cases the fixes aren't necessary in later releases so again its a matter of review.
The timely part of the process is more a resource issue, there's just not that many people and those that are working on it are generally doing either part time or in their own spare time.
Also, what is the policy on new packages? Specifically, I found myself in need of openssl098k compatibility package (need to run some binaries from F11). This is pretty trivial to come up with (change the package name from openssl-0.9.8k to openssl098k-0.9.8k in the spec file and re-tar the openssl tar ball to extract to openssl098k-0.9.8k directory instead of openssl-0.9.8k directory), but what I wanted to ask if whether there is some kind of a policy for including things like this in the main distro. It is likely that this would be useful to other people who are less willing/able to roll their own packages.
The policy on new packages is that they have to be in upstream Fedora.
How does one get a package into upstream Fedora?
https://fedoraproject.org/wiki/Category:Package_Maintainers
In most core cases there's already compatibility packages for things like openssl but it varies. Is the package that depends on older openssl it proprietary and can't be recompiled.
Of course it can in theory, but that tends to lead to dependency hell somewhere along the way, especially when the package is updated in a new version, and the updated package cannot be used.
Specifically - on the Toshiba AC100 the only kernel that works with built-in keyboard and touchpad is 2.6.29. Later versions haven't had this functionality ported forward yet.
I have an AC100 as well that I've just got booting a base F-13 image but using the 2.6.29 kernel too. I'm going to have a go at getting X etc running on the weekend.
Thus, the only kernel module for the Tegra driver that can be used is also the same one.
The Nvidia Tegra driver that is old enough to have a compatible interface with the kernel driver only has Xorg ABI 5, which means it won't work on Fedora versions later than F11.
hmm.
So, I have to have Xorg and associated drivers from F11 in order to get accelerated graphics working on this machine.
What X driver do you use for accel X?
Xorg binary links against libssl.so.8/libcrypto.so.8, which means it requires openssl 0.9.8k, so the simplest solution is binaries from F11 for Xorg with the openssl098k compatibility package.
Yea, I don't think you'll get that into Fedora mainline primarily because openssl inherently has security issues.
While I'm sure the old Xorg could be compiled up for F13, building it would probably lead to dependency hell on a Fedora 2 versions newer. Using the old binaries seems a lot less intrusive at a glance.
Can you link to where you get the X drivers etc from. I'm going to be looking at this more closely. With luck the problem of older kernels should disappear for most of the issues before long as the CE industry is moving towards standardising on 2.6.35.x for their kernel so nvidia I suspect will be already in process of upgrading to this as its what's needed for Honeycomb tablets and the like. As to when the source is released though is anyones guess.
Peter
Peter Robinson wrote:
Thus, the only kernel module for the Tegra driver that can be used is also the same one.
The Nvidia Tegra driver that is old enough to have a compatible interface with the kernel driver only has Xorg ABI 5, which means it won't work on Fedora versions later than F11.
hmm.
So, I have to have Xorg and associated drivers from F11 in order to get accelerated graphics working on this machine.
What X driver do you use for accel X?
The one bundled with the oldest downloadable L4T distribution from nvidia. I think this is the same as what is bundled in a rootfs tarball one of he other guys on the IRC channel cooled up (look for Ubuntu5.tar.lzma, IIRC). This is the only known version to work on the AC100. Note that you will also need nvrm_daemon, the kernel module, and a few dependencies for those.
Xorg binary links against libssl.so.8/libcrypto.so.8, which means it requires openssl 0.9.8k, so the simplest solution is binaries from F11 for Xorg with the openssl098k compatibility package.
Yea, I don't think you'll get that into Fedora mainline primarily because openssl inherently has security issues.
AFAIK, security issues get patches while remaining major version compatibility and APIs.
While I'm sure the old Xorg could be compiled up for F13, building it would probably lead to dependency hell on a Fedora 2 versions newer. Using the old binaries seems a lot less intrusive at a glance.
Can you link to where you get the X drivers etc from. I'm going to be looking at this more closely.
Have a look here: http://gitorious.org/ac100/pages/Installation The Ubuntu5 tar ball has everything you will need in it.
With luck the problem of older kernels should disappear for most of the issues before long as the CE industry is moving towards standardising on 2.6.35.x for their kernel so nvidia I suspect will be already in process of upgrading to this as its what's needed for Honeycomb tablets and the like. As to when the source is released though is anyones guess.
The problem isn't with the nvidia L4T, the problem is that Toshiba chose to use a really obscure interface for the keyboard and mouse in this machine.
This also isn't the full extent of the obscure sabotages/boobytraps that Toshiba have performed on this model. I recently tried upgrading the TFT panel in it, and it looks like they implemented an intercept and override of EDID coming from the panel to always report 1024x600, but even if you override the modeline in xorg.conf (note: this only makes sense when using the accelerated tegra driver, not fbdev, as fbdev isn't actually a fully implemented mode switch-capable driver on the AC100), instead of using the mode as provided. Worse, something will intercept the mode provided when ignoring EDID, and scale the image down to 1024x600, rather than using the full screen. If you put in a higher-res panel, it will never use more than the 1024x600 area in the top left of the panel. Whether the sabotage in question is out of lazyness, incompetencec or malice I don't know, but so far I'm pretty convinced that getting anything except 1024x600 to work is going to be sufficiently difficult to not be worth the effort without detailed explanation and specifications of this "feature" from Toshiba. Needless to say, the input from nvidia forums on non-trivial issues like this has been predictably non-existant.
Gordan
-
Gordan Bobic -
Peter Robinson