'divulge the chrome9 programming information': To the best of my knowledge, particularly the 3D chrome9 core has zero documentation. So there is nothing that could be 'divulged'.
S3 graphics has not developed the VIA IGP products, but VIA has. S3 would not have any more knowledge about the register map of VIA's IGP chipsets.
ATI/AMD: I still think the situation is very similar, just with a difference in the timing. I'm not saying that VIA's situation NOW is comparable to ATI/AMD's situation NOW. But it is comparable to the situation that was the case when AMD/ATI first decided to become more open on the graphics side.
I have never said that VIA is not going to publish any graphics related documentation. I am just saying that those few documents that exist (and which VIA will publish soon, don't worry!), will not be of a lot of help to driver developers, since they are only very shallow.
In many hardware companies in Taiwan (and even smaller hardware companies that I've seen in US/Europe) it is "standard practise" to not have hardware reference documentation. Sure, the pinout and electrical side is documented, since board manufacturers need to integrate the hardware.
Wit some luck there is also a register adress map, and maybe it is correct.
But an actual description of the hardware, i.e. how it works, how the state machines look like, how the flow of command works, etc. simply doesn't exist. It's just the windows driver progreammers (inside the same company) talking to the hardware engineers, either personally or on the phone.
Some time ago I spoke to one of the Intel WiFi driver authors, and he confirmed to me that with their hardware (and firmware) for the ipw2200 it is (was?) exactly the same. They had no full docs, and the software programmers just call up the hardware/firmware engineers to explain things to them. [have you noticed that there are no open doucments about any of the intel wifi products?]
So this is really not too surprising to anyone who has worked in this industry. It's basically a question about how much resources you have and how to spend them more efficiently. A much larger user base cares about working and performant [windows] drivers than anyone ever cares about documents...
Do you have any idea how many technical writers you need, for how many months, to create the documentation that Intel created for their integrated graphics? I believe it was something like 1800 pages for only one particular chipset.
Spending those resources on products that are already in the market is not reasonable. You'll always be trying to catch up with the past. If at all, you would much rather spend them on future products...
I personally have never had any issues with other FOSS projects, including operating systems like the *BSD's. In fact, prior to Linux having any decent mainline IPsec integration, I was using OpenBSD on a number of IPsec related systems. I also still regularly use FreeBSD. Oh, and I experimented with Debian GNU/Hurd in the past;)
Being somebody with an IT security and more specifically network security background, I have always appreciated what OpenBSD has achieved in this area. Also, their support for 802.11 has been and probably is much more mature than what's happening in the Linux world in recent years.
So I'm certainly not the kind of person who would try to pour oil into the flames of whatever kind of religious wars some people might be fighting.
From a VIA point of view, you have to admit though that creating drivers for the *BSD operating systems doesn't reflect the market share of those operating systems. So all we can do is release documentation (if it exists!) and maybe do the initial driver releases for Linux drivers dual-licensed (BSD/GPL) so *BSD folks can copy+paste bits from those Linux drivers.
not sure if i go to OLS next year, and how much time I have to get beer from a local microbrewery some 500 kilometers away from my current place of living. But we'll see. maybe:)
we see that delay in the past and present, for products whose R&D was not started with having a mainline mergeable driver finished when the hardware is finished. With a firm driver and mainline support strategy, you should not see that kind of delay in the future.
Slashdot Mirror
'divulge the chrome9 programming information': To the best of my knowledge, particularly the 3D chrome9 core has zero documentation. So there is nothing that could be 'divulged'.
S3 graphics has not developed the VIA IGP products, but VIA has. S3 would not have any more knowledge about the register map of VIA's IGP chipsets.
ATI/AMD: I still think the situation is very similar, just with a difference in the timing. I'm not saying that VIA's situation NOW is comparable to ATI/AMD's situation NOW. But it is comparable to the situation that was the case when AMD/ATI first decided to become more open on the graphics side.
I have never said that VIA is not going to publish any graphics related documentation. I am just saying that those few documents that exist (and which VIA will publish soon, don't worry!), will not be of a lot of help to driver developers, since they are only very shallow.
In many hardware companies in Taiwan (and even smaller hardware companies that I've seen in US/Europe) it is "standard practise" to not have hardware reference documentation. Sure, the pinout and electrical side is documented, since board manufacturers need to integrate the hardware.
Wit some luck there is also a register adress map, and maybe it is correct.
But an actual description of the hardware, i.e. how it works, how the state machines look like, how the flow of command works, etc. simply doesn't exist. It's just the windows driver progreammers (inside the same company) talking to the hardware engineers, either personally or on the phone.
Some time ago I spoke to one of the Intel WiFi driver authors, and he confirmed to me that with their hardware (and firmware) for the ipw2200 it is (was?) exactly the same. They had no full docs, and the software programmers just call up the hardware/firmware engineers to explain things to them. [have you noticed that there are no open doucments about any of the intel wifi products?]
So this is really not too surprising to anyone who has worked in this industry. It's basically a question about how much resources you have and how to spend them more efficiently. A much larger user base cares about working and performant [windows] drivers than anyone ever cares about documents...
Do you have any idea how many technical writers you need, for how many months, to create the documentation that Intel created for their integrated graphics? I believe it was something like 1800 pages for only one particular chipset.
Spending those resources on products that are already in the market is not reasonable. You'll always be trying to catch up with the past. If at all, you would much rather spend them on future products...
I personally have never had any issues with other FOSS projects, including operating systems like the *BSD's. In fact, prior to Linux having any decent mainline IPsec integration, I was using OpenBSD on a number of IPsec related systems. I also still regularly use FreeBSD. Oh, and I experimented with Debian GNU/Hurd in the past ;)
Being somebody with an IT security and more specifically network security background, I have always appreciated what OpenBSD has achieved in this area. Also, their support for 802.11 has been and probably is much more mature than what's happening in the Linux world in recent years.
So I'm certainly not the kind of person who would try to pour oil into the flames of whatever kind of religious wars some people might be fighting.
From a VIA point of view, you have to admit though that creating drivers for the *BSD operating systems doesn't reflect the market share of those operating systems. So all we can do is release documentation (if it exists!) and maybe do the initial driver releases for Linux drivers dual-licensed (BSD/GPL) so *BSD folks can copy+paste bits from those Linux drivers.
not sure if i go to OLS next year, and how much time I have to get beer from a local microbrewery some 500 kilometers away from my current place of living. But we'll see. maybe :)
we see that delay in the past and present, for products whose R&D was not started with having a mainline mergeable driver finished when the hardware is finished. With a firm driver and mainline support strategy, you should not see that kind of delay in the future.