Announcement

Collapse
No announcement yet.

Bringing Up Hardware First In Linux, Then Windows

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • droidhacker
    replied
    Originally posted by V!NCENT View Post
    Windows doesn't have 99% marketshare anymore on desktops and they lost almost all of their marketshare in the mobile market by removing all backwards compatibility in Windows Mobile 7. Just saying.

    Now a common hardware architecture among all operating systems would be good for both the companies paying for driver development and for Linux HW compatibility list.

    Having wrappers might be even better for Linux, given not all smartphone companies release newer versions of Android and having proprietary drivers kills it for the customer; he/she has to by a new phone just for an Android update.

    On the other hand this may lead to "Oh we can just make proprietary drivers for Linux.", while companies are currently more or less forced to GPLv2 it.

    On one hand I like to have Android updates for the rest of my phone's life, but on the other hand I like that the world needs to bow for FLOSS.

    But writing drivers for Linux first and then for Windows might not work.
    It is a little premature to be talking about android updates requiring new hardware due to lack of source for the hardware drivers... at this point, I can't think of a single android handset for which there are no drivers available supporting the latest version of Android. The very first android handset sold -- htc dream (one of which I have sitting about 10 inches from me this very second), has hardware drivers for everything up to and including android 2.2.

    Not that I don't agree with you in theory though, since clearly you can expect at some point that there could be a problem with hardware driver support. Good news though, is that as Android matures, the hardware driver requirements should/will_hopefully stabilize to the point where the older drivers will be reusable on newer versions. What always has been open source, and will therefore continue to be useful for future updates, are the kernel/driver glue. We can thank GPLv2 for that. This open source driver glue was very useful in the initial attempts to get 2.2 running on older hardware -- by using the 1.6 driver blobs.

    Now Android is a very different case to general desktop linux. Google has arranged it as a commercial linux desktop and has managed to be extremely successful with the platform. One of THEIR goals is to make hardware support EASY, so having a stable API/ABI is much higher on the list of priorities for this distro than for other distros.

    Leave a comment:


  • mat69
    replied
    Originally posted by DebianAroundParis View Post
    You REALLY believe you are more intelligent than everyone: kernel devs, people who dare contradict you,...why don't you create your own OS to prove the World you are the most competent man on this planet as far as operating systems are concerned? You sound so frustrated...
    I never said anything of the above and looking at your first replay you are the one that sounds frustrated to me. Yeah it's okay, trying to put bullshit into other mouths. And you wonder why I called you idiot?

    Just because I am not working on the Linux kernel does not mean that I am not entitled to have an opionion, that I am not entitled to talk about that opinion. If you aren't happy with that don't read my posts. And if there is so much wrong in my posts be free to correct them.

    Regarding kernel devs, well those are human too and contradict themselves sometimes as well, so just because they/some say something does not mean that it is always "right" -- as if there was something like that -- and in fact I do _not_ imply here that it is wrong, just that you can shove your "shut up" up your ass.

    Leave a comment:


  • DebianAroundParis
    replied
    Originally posted by mat69 View Post
    Thank you for admitting that you are an idiot.
    You REALLY believe you are more intelligent than everyone: kernel devs, people who dare contradict you,...why don't you create your own OS to prove the World you are the most competent man on this planet as far as operating systems are concerned? You sound so frustrated...

    Leave a comment:


  • curaga
    replied
    @V!NCENT, how is Android relevant in that way? Any drivers in Android kernels have to be GPL already.

    Leave a comment:


  • pingufunkybeat
    replied
    We have wrappers, and everybody hates them.

    I don't think that they are the answer to anything.

    Leave a comment:


  • V!NCENT
    replied
    Windows doesn't have 99% marketshare anymore on desktops and they lost almost all of their marketshare in the mobile market by removing all backwards compatibility in Windows Mobile 7. Just saying.

    Now a common hardware architecture among all operating systems would be good for both the companies paying for driver development and for Linux HW compatibility list.

    Having wrappers might be even better for Linux, given not all smartphone companies release newer versions of Android and having proprietary drivers kills it for the customer; he/she has to by a new phone just for an Android update.

    On the other hand this may lead to "Oh we can just make proprietary drivers for Linux.", while companies are currently more or less forced to GPLv2 it.

    On one hand I like to have Android updates for the rest of my phone's life, but on the other hand I like that the world needs to bow for FLOSS.

    But writing drivers for Linux first and then for Windows might not work.

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by allquixotic View Post
    I detect that the folks on the LKML may be aware of this situation, and if so, it sounds like they are just advocating good software architecture / design for its own sake. I think this is insanely stupid and pointless. Having beautiful software with ideal layering, coupling and object orientation is a waste of everyone's time if the software is untested crap. The purpose of writing software is not to produce code that's aesthetically pleasing to look at / contemplate; the purpose of writing software (especially device driver software) is to produce a resulting executable that does what the user (or applications acting on behalf of the user) expects.
    Actually, you're missing the maintenance and porting. The hardware will still have to be used many years after the code was written and tested, and there are many changes which will happen during this time.

    Properly written code is easier to maintain, and easier for new people to pick up after the original author disappears.

    So if you are going to try and tell me that Gallium3d is a better driver than the proprietary alternatives (even fglrx at this point), you're out of your mind. Gallium3d fails at its core mission, assuming that the core mission is to produce a high-performance, hardware-accelerated 3d graphics device driver that is able to stably and reliably support the state-of-the-art graphics APIs. It's slow, almost completely untested (if you take into account all the countless possible code paths that have never been executed before), and it doesn't support APIs that have been around for several years.
    Sorry, but Gallium3d is extremely new. It hasn't even had the chance to fail yet. In the short time since it has been introduced, it has shown to be FAR easier to develop for than the traditional Mesa way, and the progress on Gallium drivers has been incredibly fast given the small number of developers.

    Its core mission was to improve code re-use and to help new developers get involved. It has succeeded at both of these, and most of the exciting new developments (video decoding, computing, new features, etc.) have only started appearing in the free drivers after the switch to Gallium3d.

    Face it: the cathedral model of device driver development is kicking the bazaar's ass right now. We are too obsessed with getting a common infrastructure that "looks pretty" and generalizes concepts / facilities that support all conceivable hardware now and for the next 10 years. Instead, we need to borrow a little wisdom from the proprietary folks, and get things to just work.
    It's easier to get things to "just work" when you have 500 full-time programmers on your payroll writing a driver with no worries about any legal issues.

    You're comparing the work of a few hobbyists and a couple of paid programmers over 3 years to the work of 300+ full-time programmers over 15 years.

    This is clearly a bogus comparison. Pay 300 developers to develop for Gallium3d full time and then we'll compare.

    Sorry for this long rant, but I just don't see how trying to further generalize our driver architectures to be universal enough to support multiple operating systems is going to improve the actual situation with the lack of features/performance in drivers. It's basically an academic exercise with no practical utility.
    Many of the new features were simply not possible without a major redesign of the 3d driver model. You couldn't do OpenGL 2 with the old driver model of Mesa, period.

    Leave a comment:


  • mat69
    replied
    Originally posted by DebianAroundParis View Post
    Thank you for admitting you are incompetent.

    Now try to learn to shut up when you are incompetent!
    Thank you for admitting that you are an idiot.

    Leave a comment:


  • DebianAroundParis
    replied
    Originally posted by mat69 View Post

    Btw. I am no kernel dev
    Thank you for admitting you are incompetent.

    Now try to learn to shut up when you are incompetent!

    Leave a comment:


  • mat69
    replied
    Originally posted by dfx. View Post
    [...]
    and the next time some developer will write: "hey, guys, i think <this> can be better, just change it like this and like that. here, i got a patch for you!".
    they should answer with: "are you nuts ? you can't do that, we are keeping API fidelity for dudes on the Internets! they say that is only good way for kernel development and this is only way we can find enough vendor support to run it on those pesky x86 machines we have almost 0 drivers. and we also think we should remake kernel to be micro - that will show them that we mean business"

    humor us, just write your API/ABI proposal on LKML and not forget to add that entire kernel API should be like this, because it shows quality and stuff. i would really like to read some replies.

    PS: and don't start that "officially supported", "discontinued", "this is third-party fault" on me or whatnot. you talking about different models, that are performance results of those models in action.
    but they, probably, _just didn't tested my case_, riiight ?
    Great really, few examples to suit every case right? As if the FOSS stuff was tested thoroughly, just go back to read that piece of Torvalds on DRM. Or look at the oh so great Intel driver mess, crippling their already crippled hardware even more and then you see guys argueing "just use an old kernel then" or "those features aren't needed anyway", yeah say the people having different hardware. And reality check for you, this driver is all FOSS, and many years ago all the people hailed Intel for their great work as it "just works", now it doesn't anymore.

    And if you did not know, there are merge windows now already, so if you had such a great change you could get a "no merge window now, so screw you".

    It is funny that toolkits provide a stable API and there it is good and accepted, but please don't do something like that anywhere else. And the same time -- as was mentioned -- hardly any distribution is using the vanilla kernel and when there are bugs it's always the downstream's fault.

    Btw. I am no kernel dev so I would be the last one to do such a proposal, that does not mean though that it would not have a lot of good aspects as well but you are only talking about black and white here, as if things were that easy.

    Leave a comment:

Working...
X