On 3/22/10 12:22 PM, Roderick Colenbrander wrote:
Previous attempts at a Quartz driver roughly the tried to create a new driver in a design similar to winex11. If we start a new driver, the current driver design and winex11 need to be cleaned up. This requires a dib engine :( Further I expect that various pieces of code need to be moved from winex11 to wineserver/user32. I have commented on how a next generation Wine driver should operate (e.g. use software for all of GDI like windows is doing and like Win7 only accelerate some common operations like bitblt srccopy, colorfill and a few others on the GPU).
All in all, I'm quite skeptical about projects in this area sincie it is really, really, really hard.
On 3/22/10 12:56 PM, Stefan Dösinger wrote:
I think the problem with this is that it needs a proper driver
infrastructure
and putting some code from winex11 that belongs into user32 there. Nobody knows how to do it, so it is certainly beyond the scope of a gsoc
project. We
tried it before(DIB engine), and it failed miserably.
I get that, but I want to at least have a foundation for future work in this area.
On 3/22/10 12:22 PM, Roderick Colenbrander wrote:
I'd rather see the current gstreamer code finished and integrated before we perhaps add an additional backend. There are so many issues which still need to be sorted out (I believe our audio/video rendering code needs improvements and so on).
Now I'm having second thoughts about this (I know very little about DirectShow), if that's what I have to do to pave the way for a QuickTime backend. Then again, this might be a good learning experience.
On 3/22/10 12:56 PM, Stefan Dösinger wrote:
Sounds cool, although I am wondering what happened to the GStreamer
code. Was
it merged?
No. (See above.)
On 3/22/10 12:22 PM, Roderick Colenbrander wrote:
This might be useful. Not sure how trivial it is. Like Transgaming did in the past, this might require a custom osx scsi driver but note I'm not a osx user, so no idea if thiat's needed.
On 3/22/10 12:56 PM, Stefan Dösinger wrote:
My sense is that this mainly needs a replacement cdrom driver, which should stay outside of the Wine tree in a separate project(Correct me if I am wrong). That's not necessarily a blocker for making this a Wine gsoc project - it would even mean that you don't have to get all your code past Alexandre.
Yeah, now I remember we all agreed (AJ included) that we'd need to write our own driver.
I have one, I just need to start a SourceForge project or something for it. But the driver doesn't support SCSI IOCTLs yet.
One more thing: is there an echo in here? :)
Chip