wine-1.2 release criteria?

[Dan Kegel]

It's been six months since the release of 1.0,
maybe now is a good time to review the 1.2
release criteria listed in
http://www.winehq.org/wwn/353#WineConf%202008%20Keynote

One big item that wasn't listed is "make asian users happy".
I think we're starting to see some motion on that, cf.
http://bugs.winehq.org/show_bug.cgi?id=16325
This is exciting... getting this fixed might bring in a lot
of asian developers / testers / users.  I'm nominating
this one for 1.2.

The criteria listed by Alexandre were:
    * Fix the remnant bugs from 1.0 (the new 1.2 bug milestone)
    * Better desktop integration with respect to transparency and desktop mode
    * Tests that pass
Plus some 'nice to have' items. Would like at least one for 1.2:
    * DIB Engine
    * Quartz Driver
    * Direct3D 10
    * USB Support (iPod, etc.)
    * 64-bit support


Taking the  one by one:

- There are 83 open bugs nominated for 1.2:
http://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug...
We'll probably end up deferring a lot of these, and
adding a few more.  (If you think a bug not on this
list needs adding to the list, add a comment
to the bug saying "Nominating for 1.2.")

- Better desktop integration with respect to transparency and desktop mode
I don't know about this one, can somebody report on the status?

- Tests that pass
We're making progress here, but it's hard to quantify.
http://test.winehq.org shows some runs still failing
20% of the tests, and others failing 0.3%, because
we don't have a consistent set of machines running the
tests.  I would love to see that site add a feature showing
the failure history for particular machines.

Nice-to-have items:
the last status update on these two months ago is at
http://www.winehq.org/wwn/353#Updates%20on%20The%20Big%20Tickets:%20Quartz,%...
Here's what I know has changed since then:

- DIB Engine
As mentioned in
http://www.winehq.org/wwn/354#Another%20shot%20at%20a%20DIB%20Engine
Massimo picked up Jesse's DIB engine code and has been trying to
use it with Autocad.  He says he's starting to get fonts working.
(It's surprising that he chose Jesse's 2007 implementation
rather than Huw's 2008 implementation, but he said Jesse's
seemed more usable at the moment, even though Huw's
looked better in some ways).

    * Quartz Driver
Any update?

    * Direct3D 10
Any update?  And does anybody care?

    * USB Support (iPod, etc.)
No motion here, I think.

    * 64-bit support
Thanks to the gcc guy, Maarten, and Alexandre, "hello world" is
working.  Maarten is
working on relay support now.

These are exicting times for Wine... it doesn't feel like it's quite time
to start a 1.2 release countdown, but maybe in a couple months.

[Paul Vriens]

Dan Kegel wrote:
> - Tests that pass
> We're making progress here, but it's hard to quantify.
> http://test.winehq.org shows some runs still failing
> 20% of the tests, and others failing 0.3%, because
> we don't have a consistent set of machines running the
> tests.  I would love to see that site add a feature showing
> the failure history for particular machines.

I am doing this locally with my (6) testboxes. This way it's very easy to spot
differences or even flaky and inconsitent test results (see attached screenshot).

This is nice for me as I only have 1 box per OS. Not sure how this will work out
on test.winehq.org. And I'm not even talking about the extra amount of
diskspace we need for this.

-- 
Cheers,

Paul.

[Austin English]

On Mon, Dec 15, 2008 at 9:24 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote:
> Dan Kegel wrote:
> > - Tests that pass
> > We're making progress here, but it's hard to quantify.
> > http://test.winehq.org shows some runs still failing
> > 20% of the tests, and others failing 0.3%, because
> > we don't have a consistent set of machines running the
> > tests.  I would love to see that site add a feature showing
> > the failure history for particular machines.
>
> I am doing this locally with my (6) testboxes. This way it's very easy to
> spot
> differences or even flaky and inconsitent test results (see attached
> screenshot).
>
> This is nice for me as I only have 1 box per OS. Not sure how this will work
> out
> on test.winehq.org. And I'm not even talking about the extra amount of
> diskspace we need for this.

Perhaps limit it to developers, or require a registration?

-- 
-Austin

[Reece Dunn]

2008/12/15 Dan Kegel <dank(a)kegel.com>:
> - DIB Engine
> As mentioned in
> http://www.winehq.org/wwn/354#Another%20shot%20at%20a%20DIB%20Engine
> Massimo picked up Jesse's DIB engine code and has been trying to
> use it with Autocad.  He says he's starting to get fonts working.
> (It's surprising that he chose Jesse's 2007 implementation
> rather than Huw's 2008 implementation, but he said Jesse's
> seemed more usable at the moment, even though Huw's
> looked better in some ways).

What is the status of these? As far as I can tell, there are a few
changes that could be merged into wine proper, without pulling in the
respective DIB engines:

Huw -- gdi32: The dib colour table should always have 1 << bpp entries
(for bpp <= 8).
    http://repo.or.cz/w/wine/dibeng-hd.git?a=commitdiff;h=4c9188ee5e8c56aa0fb571...

Huw -- gdi32: Don't use biSizeImage for a BI_BITFIELDS dib.
    http://repo.or.cz/w/wine/dibeng-hd.git?a=commitdiff;h=892bd17b188f8afa230303...

Jesse -- gdi32: Keep physDevs consistent to driver in Blt calls
    http://repo.or.cz/w/wine/dibdrv.git?a=commitdiff;h=754f91a30771a76e4704397f3...

Jesse -- gdi32: Pass color table to drivers with SelectBitmap
    http://repo.or.cz/w/wine/dibdrv.git?a=commitdiff;h=9b60e63fd31877c7350c757bf...
> From there, it depends on whether Huw's approach, Jesse's approach or
> some other approach is the way to go. It would be useful to try and
> get the 'core' DIB engine architecture in first, so that any necessary
> changes to the architecture can be made before too much time/effort is
> spent on this.

The core should have an option to turn on the DIB engine routing, so
that it can live in the main tree without breaking existing
applications. Once the core architecture is in place, it will then be
a matter of filling in the blanks.
> From there, the selection logic (which should be fairly small -- a
> registry key check, like the Direct3D fbo setting?) can be removed.

Or am I missing something?

- Reece

[Massimo Del Fedele]

Reece Dunn ha scritto:
> 2008/12/15 Dan Kegel <dank(a)kegel.com>:
> > - DIB Engine
> > As mentioned in
> > http://www.winehq.org/wwn/354#Another%20shot%20at%20a%20DIB%20Engine
> > Massimo picked up Jesse's DIB engine code and has been trying to
> > use it with Autocad.  He says he's starting to get fonts working.
> > (It's surprising that he chose Jesse's 2007 implementation
> > rather than Huw's 2008 implementation, but he said Jesse's
> > seemed more usable at the moment, even though Huw's
> > looked better in some ways).
>
> What is the status of these? As far as I can tell, there are a few
> changes that could be merged into wine proper, without pulling in the
> respective DIB engines:
>
> Huw -- gdi32: The dib colour table should always have 1 << bpp entries
> (for bpp <= 8).
>     http://repo.or.cz/w/wine/dibeng-hd.git?a=commitdiff;h=4c9188ee5e8c56aa0fb571...
>
> Huw -- gdi32: Don't use biSizeImage for a BI_BITFIELDS dib.
>     http://repo.or.cz/w/wine/dibeng-hd.git?a=commitdiff;h=892bd17b188f8afa230303...
>
> Jesse -- gdi32: Keep physDevs consistent to driver in Blt calls
>     http://repo.or.cz/w/wine/dibdrv.git?a=commitdiff;h=754f91a30771a76e4704397f3...
>
> Jesse -- gdi32: Pass color table to drivers with SelectBitmap
>     http://repo.or.cz/w/wine/dibdrv.git?a=commitdiff;h=9b60e63fd31877c7350c757bf...
>
> From there, it depends on whether Huw's approach, Jesse's approach or
> some other approach is the way to go. It would be useful to try and
> get the 'core' DIB engine architecture in first, so that any necessary
> changes to the architecture can be made before too much time/effort is
> spent on this.
>
> The core should have an option to turn on the DIB engine routing, so
> that it can live in the main tree without breaking existing
> applications. Once the core architecture is in place, it will then be
> a matter of filling in the blanks.
>
> From there, the selection logic (which should be fairly small -- a
> registry key check, like the Direct3D fbo setting?) can be removed.
>
> Or am I missing something?
>
> - Reece

No, you aren't missing much :-)
I'm (slowly) going on with dib engine, I choose at first Jesse's one as 
starting point because it had a source file structure I liked more.
Now I'm merging Huw's one, it has ROP support, pen and brushes.... 
Stuffs are going on. I paused the font code for a while, it's very basic 
by now but I wanted to see "something" in order to test the speed 
difference in autocad.... which is awesome.
The engine still have some bugs that cause it crashing sometimes... I'm 
investigating about it before going on.
When I'll get something stable I'll post the code somewhere.
About disabling/enabling the engine, there are 4 choices :
1-by registry
2-by environment variable
3-by ./configure
4-simply removing winedib.dll.so; driver goes thru x11 if it doesn't exist.

Ciao

Max

[Vitaly Lipatov]

В сообщении от 15 декабря 2008 Massimo Del Fedele написал(a):

...
> I'm (slowly) going on with dib engine, I choose at first Jesse's one as
> starting point because it had a source file structure I liked more.
> Please if you do something with DIB Engine, publish your git repository.
> We (Etersoft) do some tests and patches too, and I am wondering why do not 
> contact with our developer chi(a)etersoft.ru

...
> When I'll get something stable I'll post the code somewhere.
> About disabling/enabling the engine, there are 4 choices :
> 1-by registry
> 2-by environment variable
> 3-by ./configure
> 4-simply removing winedib.dll.so; driver goes thru x11 if it doesn't exist.
> I guess it is a wrong way. Just use engine's function if you are sure it works 
> good.

-- 
Vitaly Lipatov, ALT Linux Team
Russia, Saint-Petersburg, www.etersoft.ru

[Massimo Del Fedele]

Vitaly Lipatov ha scritto:
> В сообщении от 15 декабря 2008 Massimo Del Fedele написал(a):
>
> ...
> > I'm (slowly) going on with dib engine, I choose at first Jesse's one as
> > starting point because it had a source file structure I liked more.
> > Please if you do something with DIB Engine, publish your git repository.
> > We (Etersoft) do some tests and patches too, and I am wondering why do not 
> > contact with our developer chi(a)etersoft.ru
>
> ...

DIB engine is progressing a bit... solved the (I hope) last crash 
problem, now BitBlt works, but still unoptimized.
Fonts partially work too.
I can run Autocad with DIB engine and, even with slow bitblt and 
unoptimized font rendering, the speed gain on True Type font display is 
impressive.
I' ve not published the git because I'm still changing some core stuffs, 
  and I want it useable and stable enough before publishing.
StretchBlt is still not done, and that's a must, IMHO.
When I'll get these stuffs ready :
    Optimized BitBlt
    StretchBlt
    Completed font rendering
    Clipping, maybe...
I'll publish the git.

A note : my DIB engine now includes both Jesse Allen's and Huw Davies 
ones, merged to take the best of both.
BTW, i'll finish it following this way, but I still think the best way 
would be to include it in wineX11.drv. Using the mixed driver approach, 
with different function pointers and physical devices depending on 
bitmap content is, imho, an ugly way to solve the problem.....

Ciao

Max

[Rolf Kalbermatter]

Massimo Del Fedele wrote:
> A note : my DIB engine now includes both Jesse Allen's and 
> Huw Davies ones, merged to take the best of both.
> BTW, i'll finish it following this way, but I still think the 
> best way would be to include it in wineX11.drv. Using the 
> mixed driver approach, with different function pointers and 
> physical devices depending on bitmap content is, imho, an 
> ugly way to solve the problem.....

It may be ugly in some ways but incorporating it in wineX11.drv has the big
disadvantage
that it would not be easy to leverage it off to other possible display
drivers such as the
quartz driver. Windows 2K/XP does appear to do it mostly in the Eng... GDI
functions
which would have been another possibility.
Vista changed the entire GDI/display driver business seriously again and I
have no idea
how it does work there.

Rolf Kalbermatter

[Massimo Del Fedele]

Rolf Kalbermatter ha scritto:
> It may be ugly in some ways but incorporating it in wineX11.drv has the big
> disadvantage
> that it would not be easy to leverage it off to other possible display
> drivers such as the
> quartz driver. Windows 2K/XP does appear to do it mostly in the Eng... GDI
> functions
> which would have been another possibility.
> Vista changed the entire GDI/display driver business seriously again and I
> have no idea
> how it does work there.
>
> Rolf Kalbermatter

Well, imho the right way would be to replace winex11.drv with a driver 
with pluggable backends, which could do all DIB stuffs as dib engine and 
forward to the backend(s) all device drawings.
Or, even better, change gdi32 to hook to different drivers for DIB and 
DDB bitmaps. I mean, every gdi function should test if bitmap is a DDB 
or a DIB and use the appropriate driver.
What I'm doing now (and what's done in Jesse's and Huw's engines) is an 
hack that swaps driver's hooks depending on bitmap type just on 
SelectBitmap() function, which has many disadvantages :
1) BitBlt functions (and maybe any call that operates on 2 BMPs) must 
check whether both BMPs are of the same kind, OR change one of them, in 
order the correct driver to operate (which is indeed done in Jesse's and 
in my engine).
2) CreateDc() and similars are called twice, once for every driver, and 
the DIB one must be done on SelectBitmap(), which is ugly.

BTW, all that would require some major cleanup of gdi code, which I 
guess nobody would like....

Max

[Pavel Troller]

> * USB Support (iPod, etc.)
> No motion here, I think.

I see a big potential here. What makes me crazy, is to beg my colleagues
running windoze to
- flash my Nokia phone with a new firmware
- Program an EPROM in a progammer
- Use an SDR (Software Defined Radio) - a box with just a radio hardware
  without any classic controls, controlled entirely from a PC
- etc. etc...
All these things have a common denominator: proprietary USB drivers. It's fine
that wine can use USB scanners/cameras/printers etc, which can be interfaced
though native Linux drivers/libraries, but these are almost always usable
directly from Linux, while those proprietary devices aren't. Is there any 
chance that wine will progress in this area ? I'm ready to supply a bounty
for a volunteer making some progress here.

With regards, Pavel Troller

[Vitaly Lipatov]

В сообщении от 15 декабря 2008 Pavel Troller написал(a):
...
> All these things have a common denominator: proprietary USB drivers. It's
> fine that wine can use USB scanners/cameras/printers etc, which can be
> interfaced though native Linux drivers/libraries, but these are almost
> always usable directly from Linux, while those proprietary devices aren't.
> Is there any chance that wine will progress in this area ? I'm ready to
> supply a bounty for a volunteer making some progress here.
> We (Etersoft) are realized USB support in wine via libusb and do many fixes in 
> ntoskrnl.exe to load and run proprietary drivers for protection keys (like 
> HASP).
> AS I know, this improvements is not acceptable by Alexandre.
> If anyone is interested to consult us to do our code more acceptable, you are 
> welcome.

-- 
Vitaly Lipatov, ALT Linux Team
Russia, Saint-Petersburg, www.etersoft.ru

[Pavel Troller]

> ? ????????? ?? 15 ??????? 2008 Pavel Troller ???????(a):
> ...
> > All these things have a common denominator: proprietary USB drivers. It's
> > fine that wine can use USB scanners/cameras/printers etc, which can be
> > interfaced though native Linux drivers/libraries, but these are almost
> > always usable directly from Linux, while those proprietary devices aren't.
> > Is there any chance that wine will progress in this area ? I'm ready to
> > supply a bounty for a volunteer making some progress here.
> > We (Etersoft) are realized USB support in wine via libusb and do many fixes in 
> > ntoskrnl.exe to load and run proprietary drivers for protection keys (like 
> > HASP).
> > AS I know, this improvements is not acceptable by Alexandre.
> > If anyone is interested to consult us to do our code more acceptable, you are 
> > welcome.

Hi!
  It sounds really very interesting! 
  Is your work accessible as a patch to the current wine tree, or as a git
branch somewhere ?
  I would like to test it with some of my apps (Nokia software, programmers
etc...) and give you a feedback, whether it works.
  Do you know, why Alexandre is not accepting your improvements ?

  With regards, Pavel Troller

wine-1.2 release criteria? (USB device support)

[Vitaly Lipatov]

В сообщении от 25 декабря 2008 Pavel Troller написал(a):
...
> > We (Etersoft) are realized USB support in wine via libusb and do many
> > ...
> >   Is your work accessible as a patch to the current wine tree, or as a git
> > branch somewhere ?
> > Please check 
> > http://git.etersoft.ru/people/lav/packages/wine.git
> > branch eterhack
> I would like to test it with some of my apps (Nokia software, programmers
> etc...) and give you a feedback, whether it works.
>   Do you know, why Alexandre is not accepting your improvements ?
> Some summarize is available on
> http://wiki.winehq.org/USB

-- 
Vitaly Lipatov, ALT Linux Team
Russia, Saint-Petersburg, www.etersoft.ru