request for Orkut wine forum manager
Hi all, If you don't know who I am, please do skip the rest of this paragraph. As you well know, I have not been as active on the Wine project as I wish. Unfortunately, this is not going to change much in the near future :-( I am currently the manager of the Wine forum on Orkut. I just got an email asking to do some operation (enabling email to members), which clarified to me that, perhaps, my lack of activity is to the disadvantage of the community members. And so, I would like to ask the esteemed members of this list. Is there anyone here who would like to take this responsibility from me? Please be sure to CC me on replies. Thanks, Shachar
Re: Direct3D, the kernel and ReactOS
On Wed, Mar 29, 2006 at 11:12:06PM +0200, Stefan Dösinger wrote: My long term suggestion is to move the Direct3D-OpenGL translation code from WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be shared with Reactos, and from a technical point of view, even Microsoft's DirectX dlls can be used on Wine(including the hardware emulation layer). If you look back at the wine-devel archives, this point was discussed at the moment 'wined3d' was started (i.e. do we go the MS way with HAL / HEL / ... or our own way with 'wined3d'). And the conclusion was that the DDK interfaces being poorly documented (no idea if they are even *publicly* documented - thus leading to all sort of legal mess if you implement Windows' internal APIs) and that they should not be used by external applications (thus enabling MS to change them for each new DirectX revision) made us choose the other way. Not to mention also that if the 'native' DDraw / D3D / ... DLLs were to work over this API, nobody would spend time working on them :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Firefox much faster with 0.9.11?!
On 3/31/06, Dan Kegel [EMAIL PROTECTED] wrote: I dunno what y'all did, but Firefox now downloads long mailing list indices much faster than it used to. Well, maybe not. It's back to being slow for me. Hrm. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Direct3D, the kernel and ReactOS
Am Samstag, 1. April 2006 11:03 schrieben Sie: If you look back at the wine-devel archives, this point was discussed at the moment 'wined3d' was started (i.e. do we go the MS way with HAL / HEL / ... or our own way with 'wined3d'). I searched the archives, but I didn't find anything. Well, IMO it's quite hard to find anything in the archives, I even have problems finding my own mail :-| And the conclusion was that the DDK interfaces being poorly documented (no idea if they are even *publicly* documented - thus leading to all sort of legal mess if you implement Windows' internal APIs) and that they should not be used by external applications (thus enabling MS to change them for each new DirectX revision) made us choose the other way. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/lowlevelclientsupport/dxlowlevelclientsupport.asp But I think one needs the ddk for more information. Many links give a 404 error :( . And the ReactOS developers say that a lot of this interface documentation is incorrect. Ms has to document all this, because the device drivers sit on the other side of this interface if I'm not mistaken. Ah, and another thing: Do not look at the ReactOS Direct3D and DirectDraw sources, GreatLord told me that they are dirty reverse engineered. (I didn't look at them eighter, luckily) Stefan pgpyaXHMX7lJB.pgp Description: PGP signature
Re: Direct3D, the kernel and ReactOS
On Sat, Apr 01, 2006 at 11:45:18AM +0200, Stefan Dösinger wrote: Ms has to document all this, because the device drivers sit on the other side of this interface if I'm not mistaken. Of course it is documented for people in companies like NVIDIA or other IHVs, but well, it's not publicly documented (AFAIK - I would gladly be proven otherwise). I would not be surprised to see the full DDK documentation coming with license agreements or NDAs. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Direct3D, the kernel and ReactOS
I havent seen any microsoft source or any other dirty stuff but what I know is that the DirectX dlls call functions like ddentryxx and gdientryxx in gdi32.dll. (there is a ddrawgdi.h file in the platform SDK I have and there is also documentation on MSDN for them) These then call system calls that thunk down into kernel. In the kernel mode code, I believe that a combination of code in win32k.sys, code in dxapi.sys, code in dxg.sys and code in the display driver are what actually do the work. (although I dont know for sure the relationship or what is going on here) Also, I dont know exactly how complete it is but I know that the windows DDK and/or the DirectX SDK includes header files like d3dnthal.h and that there is documentation for the stuff in those header files in MSDN.
Re: Direct3D, the kernel and ReactOS
Am Samstag, 1. April 2006 12:54 schrieb Stefan Dösinger:
Am Samstag, 1. April 2006 11:53 schrieb Lionel Ulmer:
On Sat, Apr 01, 2006 at 11:45:18AM +0200, Stefan Dösinger wrote:
Ms has to document all this, because the device drivers sit on the
other side of this interface if I'm not mistaken.
Of course it is documented for people in companies like NVIDIA or other
IHVs, but well, it's not publicly documented (AFAIK - I would gladly be
proven otherwise).
I would not be surprised to see the full DDK documentation coming with
license agreements or NDAs.
Hm.
http://www.microsoft.com/whdc/devtools/ddk/ServerSP1DDKEULA.mspx
Didn't read that fully yet, but if I find the time I'll read it. I think
the source code of the reference rasterizer comes with the driver
development kit. But I know that I shouldn't try to get hold of the DDK
before checking the license. Well, I guess it's a no-no for Wine developers
:-|
Just tried to read that EULA (now my brain hurts). Doesn't look too well (may
only be used to write drivers for Microsoft Windows, nothing else). Probably
invalid in the EU, but I'm not sure.
Anyway, the Vista WDF stuff seems to have a more suitable license (you may
redistribute sourcecode, writing documentation is not forbidden, and the
license even states that you may do whatever is legal with the stuff if you
don't live in the United States) AFAICT:
http://www.microsoft.com/whdc/driver/wdf/default.mspx
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
[EMAIL PROTECTED]
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
Am Samstag, 1. April 2006 00:00 schrieb Chris Morgan:
Just using the jack audio driver won't ensure that we won't see
stuttering sound. If dsound is performing hardware emulation then it
has its own internal thread that is performing mixing and other dsound
events. If this thread gets held off then you'll have no sound to
give to the jack audio drive when it runs.
Increasing the size of this dsound buffer and ensuring that it runs
seems like the easiest ways to fix issues with the dsound thread being
held off and should work for all audio interfaces assuming their
threads also run reliably.
OK, but it should work with cards that do hardware acceleration then (eg, SB
Audigy), with emulation disabled and acceleration set to full? Another idea
could be to use realtime-lsm I think (grants realtime permissions to specific
non-root users or groups)? It's quite common, anyway, even if it's not part
of the mainline kernel right now...
So, Wine could be set to a specific group (wine or audio), and we recommend to
install realtime-lsm and set it up for the wine group - that should do the
trick without having to run as root?
Optimizing DSound and the sound drivers, as well as increasing the buffer
size, is definitely another (complementary) option...
Chris
On 3/31/06, Willie Sippel [EMAIL PROTECTED] wrote:
Am Freitag, 31. März 2006 23:38 schrieb Mike Hearn:
Until it crashes your box of course...
If a Windows program has a habit of hard freezing the system then the
user will learn not to run that program.
As it is, right now _many_ games suffer this problem with corrupted
audio and it's very unpleasant (loud bursts of white noise). Makes the
games unplayable, in fact.
I'd rather make the games playable and give developers an incentive to
find a better privilege model than leave this to coast along for
another few years with only a bunch of talk, ideas and non-mainline
patches.
Right now there are no good solutions for this we can implement in Wine
itself (except maybe making wineserver suid root and drop privs), and
SCHED_ISO isn't merged into the mainline kernel, so telling users to
upgrade won't solve much.
I'm probably wrong, but in theory, if Wine used the Jack audio driver,
and jackd is suid root, the sound shouldn't stutter but Wine/ a Windows
app still couldn't hard-lock the system, as Wine would run with standard
user privileges? If that's the case, wouldn't fixing the Jack driver and
making it the preferred output plugin solve the issue? I mean, it's at
least as conveniant as suggesting to run Wine as root... ;-)
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
[EMAIL PROTECTED]
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
[EMAIL PROTECTED]
Re: Software Freedom Conservancy
Hi, On Fri, Mar 31, 2006 at 10:29:50PM -0800, Scott Ritchie wrote: On Fri, 2006-03-31 at 21:48 -0600, Jeremy White wrote: Anyone else have any objections or other thoughts on it? Let's remember that it's not just firms like Google that could give the Wine project money. Wine has some serious potential value for a whole lot of people - scientists, governments, businesses, charities, etc. What this means is that we're eligible for a whole ton of grants that nobody has ever even bothered to apply for. Uh... not to disturb this discussion or anything, but isn't this here: http://www.linuxtoday.com/developer/2006033001926NWBZDV as planned by OSDL just about EXACTLY what would be needed? IMHO administrative stuff such as project financing would best be done by one central party for many projects, due to the many legal and administrative issues involved (JFYI: the *very only* reason for the recent Lobby4Linux Austin project failure was - you guessed it - management of donation finances and nobody willing to carry that risk and responsibility!! A shame, really...). These things should *really* be centralized I think, so please push into that direction and get OSDL to widen its scope if needed and possible. This is long overdue IMHO. Andreas
Re: Keyboard Rewrite
On 4/1/06, Derek Fawcus [EMAIL PROTECTED] wrote: On Fri, Mar 31, 2006 at 01:33:18PM -0600, Tom Spear wrote: Hi all, this is a call for volunteers.I am hoping that certain developers participating in another thread are willing to rewrite the keyboard code, but we need people to test.If you are interested, please reply here saying that you are interested, and what kind of keyboard you use, as well as the layout you use under X.I will be creating a wiki page for this project once the people who will be taking on this rewrite confirm that they will do so, and will post the link to this thread as soon as it is created. The purpose of this rewrite is to (hopefully) fix all of the problems people have with key mappings, characters not showing up as expected, race conditions, characters not showing up at all, etc, and hopefully allow us to close out many of the bugs in bugzilla having to do with the keyboard. Well I'd be willing to try,as I have a peculier keyboard layout,and failedon my first attempt to hack the wine source to match,it seemed to ignorewhat I specified wrt to symbol changes.But then I did not try debugging it. I'm using a UK layout 105 key keyboard,with a few changes that make if morelike a teminal keyboard,so it is a bit of a weird mix between a USA and aUK mapping.Some of the choices derive from the fact that this is plugged in to a UK layout IBM T40,and so the extra windows are missing when usingthe native keyboard.The descriptions below apply to the layout of the external keyboard,not theylaptop layout.The key Marked 'Esc' (to left of F1) generates Backslash (or Bar when shifted) Some of the number row is remapped to be more like the USA/Terminal form: Key to left of '1!' (keycode 49) generates Escape (like a proper terminal) Shift of '2' gives At(normally Quotedbl) Shift of '3' gives NumberSign(normally Sterling) AltGR of '3' gives Sterling AltGR of '4' gives EuroSignI had to change the results generated by keys to the right of 'L' such thatthey made sense.So I also have a bunch of quotes there: The key to the right of ';:',marked as '@',keycode 48 gives the following:UnshiftedApostrophe(normal,as marked)ShiftedQuoteDbl(normally At) AltGRLeftSingleQuoteMarkAltGR+ShiftLeftDoubleQuoteMarkThe key to the right of that one,marked as #~',keycode 51 gives the following:UnshiftedGrave (normally NumberSign) ShiftedAsciiTilde(normal,as marked)AltGRRightSingleQuoteMarkAltGR+ShiftRightDoubleQuoteMarkCaps Lock (to left of 'A') gives is a duplicate Control_L,and no key generates Caps Lock The key marked '\|' to the right of the left shift key,is a duplicate Shift_LThe left windows key (between left shift and left alt) generates Super_LThe right windows key (between AltGR and Menu key) generates Super_R The Menu key (between right windows key and right control key) generates Alt_RThe AltGR key is ISO_Level3_Shift,and when shifted is Multi_key.But I've neverfound a use for Multi_key yet.DF Ok. Are these outputs that you are giving us what the keyboard shows under a native app, or what they currently show under wine? What layout do you pick under X? en_US, en_GB, pc105 no dead keys?Thanks Tom
Re: WineD3D: Do not set the mipmap level count for old textures
Am Samstag, 1. April 2006 19:34 schrieb Stefan Dösinger: The attached patch stops WineD3D from re-setting the GL_TEXTURE_MAX_LEVEL texture parameter every time a texture is used. It is not necessary, as the max level is a property of the texture and not the active unit(according to Lionel Ulmer). Setting the maximum level causes the 3d driver to dirtify the texture in the video memory, which has to be reloaded then every time it is used. This patch should greatly increase the performance of most games. (I noticed an fps improvement of a factor of 5) A small addition here: This case seems to be handled by the nvidia driver already, so the performance improvement applies only to ati cards. I tested this with my mobility radeon 9000 with the open source driver from Xorg7.0 and fglrx 8.23.7 pgpZGZEjhnFUZ.pgp Description: PGP signature
getwinegit.sh 0.32 released!
One more Version! It's time to test this script until it is one of the last versions. I don't want to spend more time into this so I desided to soonly quit this project. Here the Changes since 0.31: 0.32No Changes to Functitonality, but cool stuff :) - Better Trap-handling - Nicer Sleeper-function (I love it) - No output to the shell but only the ones by getwinegit.sh blackbox? no, everything's in the logfile - Some Fixes we all don't want to miss but I don't remeber ;)... again This release should be stable, but I want it to be tested. Tell me, if it is useful to you guys or made problems. Mail to the mailinglist if you have questions or found bugs or want something to be added. chris getwinegit.sh-0.32.tar.bz2 Description: BZip2 compressed data
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
On Fri, 31 Mar 2006 16:47:48 -0500, Chris Morgan wrote: Can't we use kernel capabilities to let people do this without having to run as root? Thats what jack audio server users are advised to do to ensure SCHED_FIFO. Could be - there are lots of options for doing this without root access. Apart from the warning which is easy to delete, this patch doesn't require root. It just tries to set the scheduler, and prints a simple tip if it fails. So, whatever schemes are used, this patch is still needed.
Re: Keyboard Rewrite
On Sat, Apr 01, 2006 at 10:59:58AM -0600, Tom Spear wrote: Ok. Are these outputs that you are giving us what the keyboard shows under a native app, Those are what one gets under native X, if one runs xev or what they currently show under wine? What layout do you pick under X? en_US, en_GB, pc105 no dead keys? Section InputDevice Driver Keyboard Identifier keyboard Option Protocol Standard Option XkbLayout gb Option XkbModel pc105 Option XkbRules xfree86 Option XkbOptions ctrl:nocaps EndSection I use xmodmap to adjust the keyboard when I start by window manager. I can send you that file as well if you wish. DF
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
Am Samstag, 1. April 2006 18:21 schrieb Willie Sippel:
OK, but it should work with cards that do hardware acceleration then (eg,
SB Audigy), with emulation disabled and acceleration set to full? Another
idea could be to use realtime-lsm I think (grants realtime permissions to
specific non-root users or groups)? It's quite common, anyway, even if it's
not part of the mainline kernel right now...
So, Wine could be set to a specific group (wine or audio), and we recommend
to install realtime-lsm and set it up for the wine group - that should do
the trick without having to run as root?
Just tested Mike's patch with realtime-lsm. Running Wine as regular user now
gives perfect audio with no stutter for every application I tried so far. So
yes, realtime-lsm actually does the trick - me happy! ;)
I load realtime-lsm with gid=18 mlock=1 allcaps=1 (gid 18 is audio), and set
wineserver to root:audio. Easy solution, great results!
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
[EMAIL PROTECTED]
Re: Keyboard Rewrite
Derek Fawcus wrote: On Sat, Apr 01, 2006 at 10:59:58AM -0600, Tom Spear wrote: Ok. Are these outputs that you are giving us what the keyboard shows under a native app, Those are what one gets under native X, if one runs xev or what they currently show under wine? What layout do you pick under X? en_US, en_GB, pc105 no dead keys? Section InputDevice Driver Keyboard Identifier keyboard Option Protocol Standard Option XkbLayout gb Option XkbModel pc105 Option XkbRules xfree86 Option XkbOptions ctrl:nocaps EndSection I use xmodmap to adjust the keyboard when I start by window manager. I can send you that file as well if you wish. DF No, that won't be necessary yet. I think once we get some devs to start coding the rewrite they wont need it tho either cause wine should default to show whatever x would show.
AppDB problem
While changing user prefences, I got this error:
Database Error!
Query: REPLACE session_list VALUES ('0b7b7e6e2b25056088b212db53619c9c',
'', '',
'current|O:4:\user\:7:{s:7:\iUserId\;s:5:\72211\;s:6:\sEmail\;s:17:\[EMAIL PROTECTED];s:9:\sRealname\;s:0:\\;s:6:\sStamp\;s:14:\20051229230938\;s:12:\sDateCreated\;s:19:\2005-07-09
01:45:14\;s:12:\sWineRelease\;s:8:\20050524\;s:17:\bInactivityWarned\;N;}',
'', NOW())
Deadlock found when trying to get lock; Try restarting transaction
Just thought this was worth reporting.
You don't have administrator privileges on this computer ... (whats changed in 0.9.11?)
Hello I just tried to make my usual test installations on the new 0.9.11 release. But at this time the setup responses (in german) Sie haben keine Verwaltungsprivilegien auf diesem Computer. Setup kann nicht fortgesetzt werden. (You don't have administrator privileges on this computer. Setup cannot be continued..). Can somebody tell me whats happend to the username mapping in 0.9.11 what can I do to avoid those messages? Thanks Roland Kaeser
