Hi,
I intend to participate in the Google Summer of Code this year, and I have several ideas for Wine that I'd like to bounce off you guys to see what you think. Note that all my proposals are Mac OS-based (I run Mac OS X), so many of you will never see the results of what I'm working on.
Here they are:
1. Quartz Driver. This is something a lot of Wine-on-Mac users (myself included) have been wanting for while now. Of course, the entire driver itself is a big project, so I would limit the scope to implementing a small piece of it--say, windowing (which shouldn't be too hard thanks to my new "Deobjectivizer" tool)--and then finishing what I started after SoC ends.
2. QuickTime backend for DirectShow. This is is similar to the GStreamer backend, but it won't require people to install GStreamer on Mac just to get this support. To get 64-bit support, we have to use the Cocoa version of QuickTime, but again, thanks to Deobjectivizer, we can avoid writing it in Objective-C.
3. Implementing SCSI support on Mac OS X. I had patches to do this, but I deleted them because I thought they were inadequate. I want to do this to get copy protection working for some games on Mac OS X.
Comments welcome.
Chip
On Mon, Mar 22, 2010 at 6:49 PM, Charles Davis cdavis@mymail.mines.edu wrote:
Hi,
I intend to participate in the Google Summer of Code this year, and I have several ideas for Wine that I'd like to bounce off you guys to see what you think. Note that all my proposals are Mac OS-based (I run Mac OS X), so many of you will never see the results of what I'm working on.
Here they are:
- Quartz Driver. This is something a lot of Wine-on-Mac users (myself
included) have been wanting for while now. Of course, the entire driver itself is a big project, so I would limit the scope to implementing a small piece of it--say, windowing (which shouldn't be too hard thanks to my new "Deobjectivizer" tool)--and then finishing what I started after SoC ends.
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.
- QuickTime backend for DirectShow. This is is similar to the GStreamer
backend, but it won't require people to install GStreamer on Mac just to get this support. To get 64-bit support, we have to use the Cocoa version of QuickTime, but again, thanks to Deobjectivizer, we can avoid writing it in Objective-C.
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).
- Implementing SCSI support on Mac OS X. I had patches to do this, but
I deleted them because I thought they were inadequate. I want to do this to get copy protection working for some games on Mac OS X.
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.
This were my comments, likely others will join in :)
Roderick
Am Montag 22 März 2010 18:49:36 schrieb Charles Davis:
- Quartz Driver. This is something a lot of Wine-on-Mac users (myself
included) have been wanting for while now. Of course, the entire driver itself is a big project, so I would limit the scope to implementing a small piece of it--say, windowing (which shouldn't be too hard thanks to my new "Deobjectivizer" tool)--and then finishing what I started after SoC ends.
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.
- QuickTime backend for DirectShow. This is is similar to the GStreamer
backend, but it won't require people to install GStreamer on Mac just to get this support. To get 64-bit support, we have to use the Cocoa version of QuickTime, but again, thanks to Deobjectivizer, we can avoid writing it in Objective-C.
Sounds cool, although I am wondering what happened to the GStreamer code. Was it merged?
- Implementing SCSI support on Mac OS X. I had patches to do this, but
I deleted them because I thought they were inadequate. I want to do this to get copy protection working for some games on Mac OS X.
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.
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
Charles Davis wrote:
Hi,
I intend to participate in the Google Summer of Code this year, and I have several ideas for Wine that I'd like to bounce off you guys to see what you think. Note that all my proposals are Mac OS-based (I run Mac OS X), so many of you will never see the results of what I'm working on.
Here they are:
- Quartz Driver. This is something a lot of Wine-on-Mac users (myself
included) have been wanting for while now. Of course, the entire driver itself is a big project, so I would limit the scope to implementing a small piece of it--say, windowing (which shouldn't be too hard thanks to my new "Deobjectivizer" tool)--and then finishing what I started after SoC ends.
Before you start down this path take a look at the WineQuartz driver project on Sourceforge. Emmanuel Mallard did a lot of work on this and I would like to revisit/assist in completing a native interface that works well with the current versions of Wine, ala OpenOffice.org. However, we have to either:
1. Make this a separate project. 2. Make sure we do not expose ObjC calling code to other platforms, they will not react well to the code and Alexandre does not like incorporating this into the main Wine trunk.
The second point has stopped most other efforts to build a non-X11 interface for MacOSX.
James McKenzie
-
Charles Davis -
James McKenzie -
Roderick Colenbrander -
Stefan Dösinger