Re: RFC: evolution of file management
This is a re-post of a message I managed to get to Ferenc Wagner, but due to my stupidity, didn't get to the mailing list: Ferenc Wagner wferi-at-afavant.elte.hu |Wine Mailing Lists| wrote: Do we need attributes like hidden, system, etc? Feri. Can't really answer your question, but on the kernel mailing list, There has been some discussion of whether these attributes should be exposed from mounted fat partitions: The fat fs maintainer has a patch, and is wondering what to do with it. (The patch exposes the fat attributes as extended attributes) See the thread titled [RFC] ioctl vs xattr for the filesystem specific attributes. Hope this helps -Rob.
Re: RFC: evolution of file management
Ferenc Wagner wferi-at-afavant.elte.hu |Wine Mailing Lists| wrote: Do we need attributes like hidden, system, etc? Feri. Can't really answer your question, but on the kernel mailing list, There has been some discussion of whether these attributes should be exposed from mounted fat partitions: The fat fs maintainer has a patch, and is wondering what to do with it. (The patch exposes the fat attributes as extended attributes) See the thread titled [RFC] ioctl vs xattr for the filesystem specific attributes. Hope this helps -Rob.
Re: Wine Status Changelog
Tom twickline-at-skybest.com |Wine Mailing Lists| wrote: Hello, Here is what I have for the Changelog thus far. There is 49 entries so far and I could have over looked something. If anything is out of place, incorrect just let me know and ill fix it. Tom Wine Status - ChangeLog Changes since May 27 2003: * New - wintab32.dll Is this in the CVS tree? Can't see it on the cvsweb page or in the repository. Cheers -Rob.
Re: Wine Status DLL's #2
Tom twickline-at-skybest.com |Wine Mailing Lists| wrote: Here is #2 any one have any comments ? Tom wintab32.dll 80% Didn't see that one come in! Nice to see it up on the list of dlls. What I'm concerned about is seeing marked as 80% done. (Aric, don't get me wrong, you've done a great job, but I think the 80% is a bit optimistic.) Why? 1. It's not even in CVS yet. 2. I think there's a lot of work to do on the patch. I can't get it to work properly for either Painter or Photoshop, but I'm getting closer. Will have a demonstration patch update on debugging out today. Aric tells me that it the code works for Codeweavers, and satisfies their needs perfectly. 3. Parts of the wintab spec are not implemented: Unicode not implemented. 16 bit calls not implemented. The Manager part of the spec are not implemented (But I doubt any users will ever need them). Tablet Z order changes are not implemented, which can be important for many more complicated apps, like CAD systems. I'd put the state of Wintab at 50% done, and once everything in point 2. is done, I'd put it at 60-75%. I suppose you could also add me as a worker on this DLL, or if you want, wait till I submit the first patch ;-) Apologies to Aric for raining on his parade. -Rob.
Wintab: Update on debugging demo patch.
Ok, Firstly, I'm including a patch that demonstrates fixes
to the crashing in Painter, and the recursion in Photoshop.
The patch assumes that you have already applied Aric's patch from April
23rd.
I'd like feedback on wether the patch is OK, as it was generated
on from my local subversion repository, not CVS.
Please bear in mind that the code is designed as quick demonstration
fixes, not for quality code. Having said that comments are welcome.
Secondly, I've done some more investigation into why Photoshop was not
seeing tablet pressure.
It turns out that this is due to Photoshop requesting tablet events from
the desktop window.
In the x11drv/event.c file, X11 events are interrogated, and the X11
window converted to a win32 window. This is done using the X11 feature
of contexts: Application specific info mapping from an X11 window to
user defined value.
It appears that the X11 window has no X11 context, and therefore the
XInput event handler is passed a hWnd of NULL.
This causes the FindOpenContext not match any context.
(Hence the recursion)
Without a context, no event is posted (Hence the lack of pressure info)
Here's a typical debug trace showing the problem:
trace:event:EVENT_ProcessEvent called.
trace:event:EVENT_ProcessEvent Got extention event for hwnd/window
(nil)/37, GetFocus()=0x40042
trace:event:X11DRV_ProcessTabletEvent Recieved tablet motion event ((nil))
trace:wintab32:X11DRV_ProcessTabletEvent Recieved tablet motion event
((nil))
trace:wintab32:WTPacketsPeek (0xc00, 64, 0x43c828c4)
trace:wintab32:WTPacketsGet (0xc00, 64, 0x1098388)
trace:wintab32:TABLET_WindowProc Incomming Message 0x7ff0 (0x,
0x)
trace:wintab32:AddPacketToContextQueue Trying Queue c00 (0 10020)
trace:wintab32:AddPacketToContextQueue Done ((nil))
Thirdly, I've found out why Painter wasn't scaling correctly.
There appear to be 2 issues.
a. Tablet coordinates should be relative to the window
the wintab context is attached to.
Currently they are absoloute.
b. The default system context as returned by WTInfo
contains zero in the lcSysExtX,lcSysExtY fields
These fields should contain the
I know how to fix the above problems, and will do so.
P.S. Aric, I can now see the race condtion problem you were talking
about in Painter.
Cheers
-Rob.
Index: dlls/wintab32/context.c
===
--- dlls/wintab32/context.c (.../file:///usr/local/svnroot/wine/trunk) (revision 73)
+++ dlls/wintab32/context.c (revision 73)
@@ -3,6 +3,7 @@
*
* Copyright 2002 Patrik Stridvall
* Copyright 2003 Codeweavers, Aric Stewart
+ * Copyright 2003 Robert North
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -168,11 +169,16 @@
ptr = gOpenContexts;
while (ptr)
{
-TRACE(Trying Context %lx (%x %x)\n,(LONG)ptr-handle,(INT)hwnd,
+TRACE(Trying Context %lx hwnd(%x %x)\n,(LONG)ptr-handle,(INT)hwnd,
(INT)ptr-hwndOwner);
-if (ptr-hwndOwner == hwnd)
+if (ptr-hwndOwner == hwnd)
return ptr;
+/* Rob 19-6-2003 Added recursion down pointer chein.
+to avoid infinite loop.
+Use TABLET_FindOpenContext as template.
+*/
+ptr = ptr-next;
}
return NULL;
}
@@ -251,7 +257,13 @@
int static inline CopyTabletData(LPVOID target, LPVOID src, INT size)
{
-memcpy(target,src,size);
+/*
+Rob 19-6-2003
+Return size only, if target is NULL:
+Was causing horrible crashes in MetaCreation's Painter 5.
+*/
+if(target != NULL)
+memcpy(target,src,size);
return(size);
}
@@ -318,39 +330,42 @@
static VOID TABLET_BlankPacketData(LPOPENCONTEXT context, LPVOID lpPkt, INT n)
{
-int rc = 0;
+if(lpPkt != NULL)
+{
+int rc = 0;
-if (context-context.lcPktData PK_CONTEXT)
-rc +=sizeof(HCTX);
-if (context-context.lcPktData PK_STATUS)
-rc +=sizeof(UINT);
-if (context-context.lcPktData PK_TIME)
-rc += sizeof(LONG);
-if (context-context.lcPktData PK_CHANGED)
-rc += sizeof(WTPKT);
-if (context-context.lcPktData PK_SERIAL_NUMBER)
-rc += sizeof(UINT);
-if (context-context.lcPktData PK_CURSOR)
-rc += sizeof(UINT);
-if (context-context.lcPktData PK_BUTTONS)
-rc += sizeof(DWORD);
-if (context-context.lcPktData PK_X)
-rc += sizeof(DWORD);
-if (context-context.lcPktData PK_Y)
-rc += sizeof(DWORD);
-if (context-context.lcPktData PK_Z)
-rc += sizeof(DWORD);
-if (context-context.lcPktData PK_NORMAL_PRESSURE)
-rc += sizeof(UINT);
-if (context-context.lcPktData PK_TANGENT_PRESSURE)
-rc += sizeof(UINT);
-if (context-context.lcPktData PK_ORIENTATION)
-rc
Re: Wine Status Changelog
Jeremy Newman jnewman-at-codeweavers.com |Wine Mailing Lists| wrote: On Thu, 2003-06-26 at 07:39, Robert North wrote: Is this in the CVS tree? Can't see it on the cvsweb page or in the repository. Nope, not in CVS yet. Once Tom sends me a patch at wine-patches, I will commit them to the site. Just to clarify: I was talking about the wintab32 dll, *not* the changelog itself. Are we talking about the same thing? -Rob.
Re: Wine Status Changelog
Sylvain Petreolle spetreolle-at-yahoo.fr |Wine Mailing Lists| wrote: Of course, its already in the tree... see the CVS : http://cvs.winehq.org/cvsweb/wine/dlls/wintab32/ Oh, sorry, I'll clarify: The CVS currently has stubs (I think contributed by Patrick Stridvall). They were contributed in late 2002/early 2003. Aric's patch to actually provide functionality (from April 2003) has not yet been applied. He's going to re-work it to have better dll separation. (See his recent post) Cheers -Rob.
Re: Wintab: Update on debugging demo patch.
Aric Stewart aric-at-codeweavers.com |Wine Mailing Lists| wrote: I chatted with Alexandre yesterday and he expressed a number of concerns with how my patch works. He and I are going to work on make that patch suitable for winehq. Then i will get that applied. It should not change any of the functionality. Just trying to preserve DLL separation. Can you discuss a bit further what the separation issues are. I did some thinking about this when I was initially discussing a wintab implementation. Might be a useful reference for other people looking at dll separation issues. Then i will work with your patch to get that stuff in as well. One, thing.. could you do add a -w to your diff so that we can ignore the changes in white space. that will cause the patch to be smaller and easier for me to see what changes you made. thanks -aric Ok, so you'll integrate the patches I sent. One suggestion: When you apply the patches, re-work the Packet reading functions to make the flush vs. read functionality clearer. My patch doesn't make the difference clear to the casual observer. If you want I could do this re-working after you've posted your new patch. I will work up some fixes to the Photoshop, and Painter issues with the current code, and release patches aganist your forthcoming patch. Unless you want to do that? Cheers -Rob.
Re: Wine Status Changelog
Robert North 7ownq0k402-at-sneakemail.com |Wine Mailing Lists| wrote: Sylvain Petreolle spetreolle-at-yahoo.fr |Wine Mailing Lists| wrote: Of course, its already in the tree... see the CVS : http://cvs.winehq.org/cvsweb/wine/dlls/wintab32/ Oh, sorry, I'll clarify: The CVS currently has stubs (I think contributed by Patrick Stridvall). They were contributed in late 2002/early 2003. Aric's patch to actually provide functionality (from April 2003) has not yet been applied. He's going to re-work it to have better dll separation. (See his recent post) Cheers -Rob. I think I'm actually being a total idiot here. I'm confusing the changelog for Tom's Status page with the changelog for the whole project. If this is the case then please disregard all my messages on this thread. Apologies -Rob.
Re: Bidi B patch
Alexandre Julliard julliard-at-winehq.org |Wine Mailing Lists| wrote: Jeff Smith [EMAIL PROTECTED] writes: I'm sorry, so maybe it is not necessary, but how does doing it the 'right way' add confusion? There is no 'right way', inside the source tree both are completely equivalent. Changing it adds confusion because you now have 1000 files doing it one way and 3 files doing it differently for no good reason. This thread has been confusing me. I was under the impression that when appropriate people should be changing includes to . I was wondering why I had this impression, and then remembered this section on the wine janatorial page: `Include statements should use instead of ` Is this now incorrect? Confused -Rob.
Re: Wintab dll: Status report.
Aric Stewart aric-at-codeweavers.com |Wine Mailing Lists| wrote: Interesting. Since I had myself as well as at lest 3 other organizations of testers testing this code at each step with Photoshop6 and 7 and Painter 7 as well as a number of test applications. None of us saw these problems. What I found, and could fix: Sometimes a badly configured tablet can generate X errors on the XOpenDevice method. Fixed by ensuring tablet driver was functional. I don't know if the errors need to be caught, or not, but I think they were causing crashes. This is probably related to synchonous/asynchonous X modes. Was XOpenDevice returning a device but also creating errors? That seems really counter intuitive since it is only suppose to return the device if it succeeds. However I am not much of a x11 programmer. When this error occurred where was the crash? probably at some point where I am gathering the tablet information. It would be good to find that line and fix it there also. I will have to re-produce the error first. That could be difficult: hardware in linux tends to work very well, or very badly. My tablet is currently working very well. I could have confused the crash from one of the null pointer errors, so I'm beginning to suspect this could have been a red herring. In Photoshop, an infinite loop in method FindOpenContext when attepting to traverse the wintab context chain. Something is going seriously wrong here if there is an infinite loop. The contexts should be a linked list so someone's next is pointing to something previous in the list. WHen i did photoshop it created only 2 contexts (and only did anything with 1 of them) both where contexts to the root window. Where is this loop being created? It's actually pretty clear from the code: The following referes to the context.c file in fuction TABLET_FindOpenContext, line 129 is: ptr = ptr-next; in function FindOpenContext there should be an equivalent line, after line 175. If you still want more information about then this occurs, I can provide it. In Painter, a number of methods didn't handle NULL prameters properly, resulting in various crashes. Wintab uses NULL paramters to signify a query for size of available data, or to signify a request to flush the Wintab packet queue. Which methods? I thought that i had handled all the cases i had seen used this way. WTInfoA, fails for standard wCategory, or nIndex values if lpOutput == NULL. Fixed by modifying CopyTabletData to suppress memcpy if target == NULL. WTPacketsGet,WTPacket,WTPacketsPeek,WTDataGet will all fail when passed a NULL lpPkts. I've only really fixed this for WTPacketsGet,as this was the only one where it caused crashes/ Also another bug I neglected to mention what that many of these functions flush the buffer using memcpy, to copy overlaping sections. Aric, I'm wondering if I should really be fixing these things, as these look like the kind of bugs Code Weavers will have fixed in the normal course of product support. Like I said, We saw none of these problems. It was working wonderfully for me, and all our tester and customers. So if you need to fix things for your tablet then you should fix them because I cannot reproduce it here at all. In that case, I wonder if it could be due to different compiler/library versions, and static vs. dynamic linking? The first thing you need to do is make sure that your tablet is working under X. There is a great little program called xinput, it is a utility that test the XInput module. You can see all the axis of your device and make sure they are working. I found that to get XInput to recognize pressure from my wacom tablet i needed to run the latest wacom drivers from http://linuxwacom.sourceforge.net/index.php/main. you can download xinput from ftp://ftp.x.org/contrib/utilities/xinput-1.2.tar.gz My tablet works fine with Gimp. I'll have a look at the latest wacom drivers, and at the XInput extension. I'll run the test program as a sanity check. Infact the XInput extension could be what's causing the scaling to go funny. When I said I was suspicous of the scaling data from the wacom driver, I really meant XInput. I've been avoiding patching XInput dll so far. Aric, are these the kind of bugs you were seeing with Painter? no actually, the problem I was seeing was a race condition inside painter with the button/pressure testing code. Such that after you lifted the stylus painter would still think that the stylus was in contact with the pad and keep drawing. Ok, So not there yet :-( I'm suspicious of the Wintab packet building code, as it has to build a C data struct on the fly. Looking at the code though, I can't see anything that could be going wrong. It could also be a scaling issue, where the scales deduced from X are wrong (I remember being suspicious of some of the values returned by the wacom driver). This i tested alot with my own test
Wintab dll: Status report.
Ok, I've done some preliminary testing, and fixed obvious bugs that have arisen. What I found, and could fix: Sometimes a badly configured tablet can generate X errors on the XOpenDevice method. Fixed by ensuring tablet driver was functional. I don't know if the errors need to be caught, or not, but I think they were causing crashes. This is probably related to synchonous/asynchonous X modes. In Photoshop, an infinite loop in method FindOpenContext when attepting to traverse the wintab context chain. In Painter, a number of methods didn't handle NULL prameters properly, resulting in various crashes. Wintab uses NULL paramters to signify a query for size of available data, or to signify a request to flush the Wintab packet queue. Aric, I'm wondering if I should really be fixing these things, as these look like the kind of bugs Code Weavers will have fixed in the normal course of product support. After fixing these issues, The following remain: 1. Photoshop doesn't seem to respond to pressure. 2. Painter receives wintab events, but coordinates are extreme: only see lines from one side of drawing to another. 3. Maybe some further research into the errors from XOpenDevice. I'm not convinced it is a problem. Aric, are these the kind of bugs you were seeing with Painter? I'm suspicious of the Wintab packet building code, as it has to build a C data struct on the fly. Looking at the code though, I can't see anything that could be going wrong. It could also be a scaling issue, where the scales deduced from X are wrong (I remember being suspicious of some of the values returned by the wacom driver). I've got tons of trace code that runs as a wrapper round wintab on win98, and will move some of this into the wine impl for more testing. I hope this will help solve the remaining bugs. I think in the light of the crashing bugs, Aric's patch shouldn't go in as-is. If people want, I could post up a patch with the fixes I've added so far. That's all for now. -Rob.
Re: Wintab: beginning to investigate Aric's patch from April.
Aric Stewart aric-at-codeweavers.com |Wine Mailing Lists| wrote: Hi Robert, No problem with the timing. The first thing I'm seeing is a crash in the WTInfo() wintab call with Painter 5. Will look into this further, and attempt to fix. Aric: Ever had this? I'll investigate further before posting up any significant details, as I suspect the fix is trivial. This is new to me. i believe the version of painter i tested against was painter 7. So i am not sure what Painter 5 does. Generally I have a tendency to overload the TRACE channel when i develop. so maybe a good +wintab32 log will help. I think actually it's my X config that's breaking the system. I'm in the middle of debugging it now. I haven't tried Photoshop with the patch, but I suspect it will fail too. I haven't looked any further into Aric's other problems with Painter, as this WTInfo() error prevents Painter from even starting! I have a number of exe files i downloaded from the wacom developers site that test tablets in various ways. do you want me to send them to you? I've probably got them already Tell me the file names first, and send me any I don't recognise. More importantly, I'd like to know why it didn't make it into the CVS? Did the patch slip behind the filing cabinet (as they do ;-)? Or was there a more substantive reason to reject the patch? I think Mike Hearn mentioned something about it's size (v. large)? Aric, Alexandre: do you want me to want me to re-subimt the patch, once I've got WTInfo() working? I think we where waiting on you. :) I did not formally commit it to wine-patches because i wanted to get your input first. Ah! Fair enough. I would like input from other developers, as I can't comment on Wine style/policy issues, being somewhat of a newbie to the project. In particular I think the x11drv developers might want to comment. Of course, maybe this has already been done 70-90% by internal Codeweaver reviews. If you are planing to expand on my patch, then i would say Alexandre should could commit my patch then you work from there. Whatever is easiest for you. I've also noticed that it doesn't update Wine's autoconf file to look for the XInput X extension, as is done to support other dlls that use X extensions. I assume this should be added. actually i worked to make all the XInput stuff loaded dynamically to handle systems where XInput may not be present. I am not sure what would be required for building. If that is a step that is necessary and i missed please do. It's a build time check. You've already got the run-time check for the library. I think it's just checking XI.so exists, and that the XI.h XInput.h files exist. Then in the X11drv/wintab.c, make compile conditional on the existance of headers library. (Just a rough sketch, names are likely wrong) Just to touch base with Aric: Has anyone done any more work in Code Weavers on this? Nope, you have the latest and greatest i believe. I know i did some work to try to fix painter but I did not succeed and actually fixing anything so i did not save that additional work. (it was mostly just guessing an various structure initialization) If after the winecvs commit i find anything divergent i will send that do you. -aric
Wintab: beginning to investigate Aric's patch from April.
Ok, I've just managed to start looking into Aric's Wintab32 patch from April 23rd. I've been extremely busy (more so than I expected) since then, on a small Java contract. So I've missed my goal of looking into Aric's code in 3 weeks. (Apologies Aric) But anyway, I'm starting to look into it. The first thing I'm seeing is a crash in the WTInfo() wintab call with Painter 5. Will look into this further, and attempt to fix. Aric: Ever had this? I'll investigate further before posting up any significant details, as I suspect the fix is trivial. Infact, has anyone else looked into this patch? I haven't looked any further into Aric's other problems with Painter, as this WTInfo() error prevents Painter from even starting! More importantly, I'd like to know why it didn't make it into the CVS? Did the patch slip behind the filing cabinet (as they do ;-)? Or was there a more substantive reason to reject the patch? I think Mike Hearn mentioned something about it's size (v. large)? Aric, Alexandre: do you want me to want me to re-subimt the patch, once I've got WTInfo() working? I've also noticed that it doesn't update Wine's autoconf file to look for the XInput X extension, as is done to support other dlls that use X extensions. I assume this should be added. Just to touch base with Aric: Has anyone done any more work in Code Weavers on this? That's all for now. -Rob.
Re: Missing Bugzilla Descriptions
Dustin Navea speeddymon-at-yahoo.com |Wine Mailing Lists| wrote: Hey guys i was browsing thru BugZilla and I noticed that most if not all of the bugs between 853-1349 are missing their descriptions.. Possibly from the software update? Either way, I'm still around every now and then, although I'm not subscribed to any lists, so if anyone replies, please CC me __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com Just noticed that! 2 *important* bugs for me 1160 1165 are missing any comments. 1165 in particular, contained some useful debugging info ... I suppose it's a good thing that it seems to be resolved in the current CVS! Any ideas? -Rob.
Re: WS_EX_TRANSPARENT bug
Mike Hearn m.hearn-at-signal.qinetiq.com |Wine Mailing Lists| wrote: I would have added this to the bug, but I don't have access to my bugzilla password right now (why oh why didn't i change it!). Anyway, we can't implement this currently, X11 doesn't support transparent windows :( Not quite true See the following: http://www.eax.com/render/#d4 Transparency galore!! Note: One method only works of a CVS version of Xft/Xrender. extension(s?) The other works using the shape extension. It's prossible, but not necessarily trivial -Rob. P.S. Apologies to Mike, sent first version of this message Bcc Wine devel.
Doccumetation issue: The Service Thread Does it exist?
This concerns the documentation on thw www.winehq.com website, if it's out of date, then this post may be irrelevant. In the Wine Developer's Guide In Section 8.1.4, The Service thread Says there exists a service thread, that is implemented in: scheduler/services.c. It also says this thread is used to support the X11 driver's event loop. Firstly, I cannot find the scheduler/services.c file. Secondly from my reading of the x11drv code, the X11 event loop is serviced for every call of to X11DRV_MsgWaitForMultipleObjectsEx, which is inturn called by MsgWaitForMultipleObjectsEx, and GetMessage. Therefore, whichever thread is active will service the X11 event queue. It also appears, because each thread has it's own XDisplay object that messages created by a X11 window will only be picked up in the thread that created the window. Am I correct, or have I missed something fundamental? Bye -Rob.
Re: Doccumetation issue: The Service Thread Does it exist?
Vincent Béron vberon-at-mecano.gme.usherb.ca |Wine Mailing Lists| wrote: Robert North a écrit: This concerns the documentation on thw www.winehq.com website, if it's out of date, then this post may be irrelevant. In the Wine Developer's Guide In Section 8.1.4, The Service thread Says there exists a service thread, that is implemented in: scheduler/services.c. It also says this thread is used to support the X11 driver's event loop. Firstly, I cannot find the scheduler/services.c file. [Snip irrelevant stuff] From http://cvs.winehq.org/cvsweb/wine/scheduler/Attic/services.c: Revision 1.14 FILE REMOVED Removed service thread support. Guess it answer why you can't find scheduler/services.c. Somebody else than me can probably tell you why, or what replaced it. Vincent Now why didn't I think of doing a CVS search ;-) Did a google on the winehq site, and found that Alexandre wanted to remove it, but not why. I'll just have to wait for further replies. Thanks -Rob.
Re: Help wanted: Implementing Wine dlls that need access to X11 commands.
Enrico Horn farmboy1-at-subdimension.com |Wine Mailing Lists| wrote: Hi, On Wednesday 15 January 2003 19:09, Robert North wrote: Robert North 7ownq0k402-at-sneakemail.com |Wine Mailing Lists| wrote: Now, as it turns out, the methods to interrogate a wintab message queue are extremely similar to those to interrogate an X11 message queue. So that's +1 to giving wintab it's own X11 message queue. (Or possibly even one X11 msg queue per tablet context!). A simple X11-wintab mapping can be implemented, and no additional queue data structs are needed in the wintab implementation. I'm not convinced you can avoid managing an event queue for wintab events; from a quick look at the spec I doubt you can simply map the wintab functions to X11 queue functions. I'm about to have a final look at this, see if there is a clear mapping from X11 functions to wintab. More on this once I've completed my investigations. One mismatch is that wintab uses a fixed size message queue which can be defined as, as opposed to Wine or X11. (I'm assuming wine or X11 are either extremely large queues, or dynamically sized.). I've re-checked the X11 code, and you're right, the only sane way to map X11 events to a wintab queue is by coding an event queue for wintab. Thanks -Rob. Sorry if this seems like a stupid question. Don't think it is, It's the question I've ended up trying to answer when looking at how best to implement wintab. Could you please elaborate what the problems between X11, DirectDraw, OpenGL and accessing X11 functionality are. I am not an expert in either area but like to understand the problem. I'm not the person to answer this, but answering it will help me clarify my own thoughts, and allow people to correct me :-) Well, it seems that wintab now has the concept of drivers, at least for graphics (sound??) As I currently see it the problem is a question of policy: What should be in the x11drv dll (a private? dll) and what should be in the application facing dlls. Currently, the x11drv dll does not appear export any X11 data stuctures, or handles. Therefore my assumption is that code that interfaces with the X11 system should go in x11drv. This means that x11drv could become horribly bloated with support for specialist dlls like x11drv. Also, as I've mentioned before, x11drv is so important to the functioning of wine, unnecessary tinkering here gould cause nasty regressions. As Alexandre points out, wintab code need not interact much with current x11drv code, and therefore if well designed, will cause minimal regression risk. And yet, DirectDraw, OpenGL dlls do access the X11 system directly. How? By some clever hacks to get X11 display objects from gdi and X11 window handles from Wine window handles. And is this good policy? No. Lionel has pointed out that these dlls are bad examples of how to do it. So, what is the policy? I dunno. Maybe it's use your head? Hope this helps -Rob. Thanks Enrico
Re: Help wanted: Implementing Wine dlls that need access to X11 commands.
Robert North 7ownq0k402-at-sneakemail.com |Wine Mailing Lists| wrote: Now, as it turns out, the methods to interrogate a wintab message queue are extremely similar to those to interrogate an X11 message queue. So that's +1 to giving wintab it's own X11 message queue. (Or possibly even one X11 msg queue per tablet context!). A simple X11-wintab mapping can be implemented, and no additional queue data structs are needed in the wintab implementation. I'm not convinced you can avoid managing an event queue for wintab events; from a quick look at the spec I doubt you can simply map the wintab functions to X11 queue functions. I'm about to have a final look at this, see if there is a clear mapping from X11 functions to wintab. More on this once I've completed my investigations. One mismatch is that wintab uses a fixed size message queue which can be defined as, as opposed to Wine or X11. (I'm assuming wine or X11 are either extremely large queues, or dynamically sized.). I've re-checked the X11 code, and you're right, the only sane way to map X11 events to a wintab queue is by coding an event queue for wintab. Thanks -Rob.
Re: Help wanted: Implementing Wine dlls that need access to X11 commands.
Thanks for your reply... It's really got me thinking, and unforunately, has caused more questions than answers. Luckily many of the questions may be useful to the wine developer community at large. Alexandre Julliard julliard-at-winehq.com |Wine Mailing Lists| wrote: Robert North [EMAIL PROTECTED] writes: But note that this would reqire some patching to the x11drv dll to do the following 1. decode the messages. 2. enable the messages for a given window and display. But I'm assuming that changing the x11drv code could cause severe regressions to wine. I'm therefore assuming that it's good manners to avoid fiddling with x11drv code till the wintab driver implementation is known to be adequate. I don't think it would necessarily cause regressions to simply add handling for new events, since it shouldn't require changing the existing event handling. But anyway writing a separate prototype first is certainly a good idea. Hmm. Interesting This raises the issue of code separation: For any new wine dll, that needs new X11 calls, what code should go into x11drv dll and what into the new dll? I tried to make sense of this issue by referring to direct draw and open gl dlls, but just got more confused. The danger I see is that 90% of the wintab code, (and there could be quite a bit) might end up in x11drv, and 10% in wintab! This is especially likely if the policy is expose no X11 structs through the dll exports of x11drv. The issue of prototyping brings me to issues about how to release patches to wine, which I think I'll discuss in a future e-mail. Now, as it turns out, the methods to interrogate a wintab message queue are extremely similar to those to interrogate an X11 message queue. So that's +1 to giving wintab it's own X11 message queue. (Or possibly even one X11 msg queue per tablet context!). A simple X11-wintab mapping can be implemented, and no additional queue data structs are needed in the wintab implementation. I'm not convinced you can avoid managing an event queue for wintab events; from a quick look at the spec I doubt you can simply map the wintab functions to X11 queue functions. I'm about to have a final look at this, see if there is a clear mapping from X11 functions to wintab. More on this once I've completed my investigations. One mismatch is that wintab uses a fixed size message queue which can be defined as, as opposed to Wine or X11. (I'm assuming wine or X11 are either extremely large queues, or dynamically sized.). I think after all that complexity, that's +4 or more to X11 message queue implementation, and for wintab at least, avoid the wine message queue. I agree you probably don't want to store wintab events in the Windows message queue. But that doesn't mean you have to create your own X connection and event loop, you can simply retrieve the events from the normal X event loop and store them into the wintab queue. Which is initially how I was going to implement it. The issue I came up against is how to inject the messages into the wintab queue? In wine, messages are currently injected into the for each thread, when GetMessage() is called. As wintab has it's own equivalent of GetMessage (named WTPacketsGet) the which seems to have direct access to the driver, it would look like wintab needs an alternative method to inject messages into it's queue. The only one I could come up with, in wine style, was to have a worker thread whose sole purpose is to inject messages into the wintab message queue. It might call GetMessage(), but all this would do is cause the wine message loop to insert a message into the wintab loop. The problem with this system is that it means that the queue has to be accessed by multiple threads, and therefore will lead to the usual thread synchronisation hassles. It was the fact that I could avoid synchronisation which lead me to think about building my own message loop.
Re: Help wanted: Implementing Wine dlls that need access to X11 commands.
Lionel Ulmer lionel.ulmer-at-free.fr |Wine Mailing Lists| wrote: I tried to make sense of this issue by referring to direct draw and open gl dlls, but just got more confused. Do NOT look at DirectDraw or OpenGL for references as how it is done... The current stuff there are mostly hacks to get the DLL separation to work (ie for DDraw, it should go through a proper HAL and for OpenGL, it's not documented how Windows did it, so we did our own hacks). So, that explains why I got confused ;-) But I face a similar problem of dll separation. Infact anyone who has to access X11 features not exposed in x11drv will face dll separation problems. So, in hindsight, what advice would the DirectDraw or OpenGL developers give to someomne facing dll separation problems? Thanks -Rob.
Help wanted: Implementing Wine dlls that need access to X11 commands.
I'm about to start serious implementation on the wintab32 dll. I now need some guidance as to how best to implement it's access to X11 calls. My current thoughts on how to do this are given below. Are they reasonable?? I need to access a number of X11 calls, largely in the XInput extension. None of these are exposed by the x11drv dll. My intention is currently to change nothing in the x11drv dll. The only hints I can find about how to do this are from the direct draw and open gl dlls. These dlls can do the following: Get the X11 Display object of a gdi context. Get the X11 window handle given a win32 window handle. Synchronise with the x11_drv code for multi threading. My wintab code will do the same. The one difference will be that wintab will create it's own X11 Display objects. It will interrogate a gdi's X11 Display object to ensure it talks to the same screen. The wintab code will also require multiple message queues. To implement this I intend to use one display object per queue. (Much as wine uses one display object per thread) Hope I'm on the right track -Rob.
Re: Help wanted: Implementing Wine dlls that need access to X11 commands.
Alexandre Julliard julliard-at-winehq.com |Wine Mailing Lists| wrote: Robert North [EMAIL PROTECTED] writes: The one difference will be that wintab will create it's own X11 Display objects. It will interrogate a gdi's X11 Display object to ensure it talks to the same screen. The wintab code will also require multiple message queues. To implement this I intend to use one display object per queue. (Much as wine uses one display object per thread) Hmmm... I have a feeling you would be better off using the existing message queues and display connections. Could you give a bit more details on how you have to implement it, or send us pointers to the relevant documentation? That's what I thought, and I have proof of concept patch that hack the x11drv code to insert read XInput events from wine's X11 event loop. Unfortunately this doesn't fit well with the way wintab works. So, here's an explanation, why I've made these decisions. It's far longer than I'd wish, but the issues involved in the design are complex. So here goes.. ***Quick recap of what wintab does*** The wintab dll will takes messages from a graphics tablet, and provides them to the user. But isn't that what a mouse does? A mouse provides information on the X Y screen coords, and buttons pressed. A tablet provides all the above, plus extra axes defining the tilt of a pen, the pen's pressure, rotation of a mouse, (and possibly more). All this can be provided at resoloutions much higher than screen resoloution. ***The XInput side of the implementation *** The official way to get tablet data for an X display is to use the XInput extension. The XInput extension defines a specialised set of event classes to represent tablet data, which enter the normal X11 message queue. These messages are initially disabled. XInput provides a function to enable them for a given display and window. OK, So far it looks as if the XInput messages could be injected into the wintab messaging system. But note that this would reqire some patching to the x11drv dll to do the following 1. decode the messages. 2. enable the messages for a given window and display. But I'm assuming that changing the x11drv code could cause severe regressions to wine. I'm therefore assuming that it's good manners to avoid fiddling with x11drv code till the wintab driver implementation is known to be adequate. *** The wintab side of the implementation *** To access tablet, a tablet context is created that maps a window to a particular tablet device. For each tablet context the application is given a separate tablet message queue, which provides 2 ways to access the tablet message queue. a. A set of functions that get or peek, or otherwise interrogate the message queue for queue size, message at index etc. b. Posting messages into the windows(wine) message queue. To complicate matters, it appears that it's possible to use both methods in the same program. At present, I will only implement method a. as this is the one used by Painter5 and Photoshop6. Now, as it turns out, the methods to interrogate a wintab message queue are extremely similar to those to interrogate an X11 message queue. So that's +1 to giving wintab it's own X11 message queue. (Or possibly even one X11 msg queue per tablet context!). A simple X11-wintab mapping can be implemented, and no additional queue data structs are needed in the wintab implementation. As the wintab dll implements it's own message queue, an implementation using the wine message queue would give a number of problems: 1. All wintab messages would have to be hidden from the application's windows(wine) message queue. Could be done with one specific thread, or threads for wintab. This becomes similar, but more complicated to the X11 message queue implementation. 2. Filtering methods would have to be implemented to only access the messages appropriate to the reqired tablet context. X11 provides all the filtering necessary. While windows provides enough filtering for ranges of messages. But this would mean 3 message mappings X11-windows(wine)-wintab. 3. All the queue management functions, and any necessary data structs to manage the queue will have to be implemented specifically in wintab, as the windows queue doesn't give much control over the message queue, and what's more, may need to copy data into a wintab specific message queue before the application can access it. I think after all that complexity, that's +4 or more to X11 message queue implementation, and for wintab at least, avoid the wine message queue. Well, that's the end of my whistle stop tour of the issues I've been cosidering with this part of the design. I've omitted any reference to function names, to keep this document as breif and readable
Re: [RFC] wintab dll design: how to intergrate with current X11 code.
Right, can now ignore my original post, and comment on the following. Ok, I've sort of found a template for the X11_drv wintab seperation: The tablate is the direct X drirect draw, and open GL dlls. These dlls do the following: X11_drv thread synchronisation Grab the X device the GDI code uses. (I only want to grab the same display string, and build my own XDisplay object). Get the X window handle from a win32 window handle. This is all that's needed to attach the wintab dll to the XInput code. I shall put no extra code in the X11_drv. All XInput calls will live in the wintab dll. One fly may appear in the ointment: It is possible for the X11 driver to insert wintab messages into wthe win32 message queue. This can be handled entirely inside the wintab dll, but the tablet messages may get out of sync with the rest of the windows messages. If the messages do get out of sync, then wintab may need to hook into the event code int x11_drv/event.c. For the moment I'm assuming this won't happen. That's all for now Merry Christmas -Rob.
[RFC] wintab dll design: how to intergrate with current X11 code.
Ok, I'm about to start some serious implementation on the wintab dll. What I need now is some giudance as to how to proceed, regarding integration with X11 code. Please comment on anything mentioned below. If this is too concise, please ask for further clasification. *Requirement for interfacing with X11* To access the graphics tablet, the dll must access the XInput extension to X11. Therefore it needs some level of cooperation/integration with x11_drv. The reqirements are: Access to an XDisplay object. Event dispatch code similar to event.c It must be able to claim XInput events, and expose them through the wintab32.dll interface. Wintab32.dll is defined as having it's own event dispatch system, totally distinct from the win32 system. Access to an X window that contains the wine/win32 window client area. This is available in a win32 property named: __wine_x11_client_window. It is also accessible through x11_drv internals. If necessary, could always use the DefaultRootWindow(display)!. *Assumptions** It is bad practice/impossible to call functions from one dll in another, if they are not defined in the .spec file. I'm also assuming the same applies to variables. A call to XOpenDisplay(NULL) will ensure the same display is accessed as in X11_Drv. It is a good idea to call XInput functions in the wintab32.dll. It is a good idea to access the X11 windows needed by the Win32 window's propery. will reqire that the GetProp and GlobalFindAtom functions in wine. Wintab can be given it's own version of WaitForMultipleObjectsEx that will deal solely with XInput events. I'm also assuming that there is no reason why XInput events should occur in ***Questions*** Is function X11DRV_MsgWaitForMultipleObjectsEx really the place where all X11 events enter the system before being translated into win32/16 events? It appears to be a principle of wine design that all X11 code should live in the x11_drv dll. Therefore, when complete, where should XInput code live? *Design principles** Genericity. I would like anything in X11_drv to be as generic as possible. So, Initially, I'd like to keep code in X11_drv to a minimun. Therefore, Given the ideas above, all XInput code is in wintab32.dll! ** And that's it! *** Well that's the lot, Please comment Cheers -Rob.
Re: Painting message order?
Paul Millar paulm-at-astro.gla.ac.uk |Wine Mailing Lists| wrote: On 3 Dec 2002, Mike Hearn wrote: It sends WM_PAINT, the does the NCPAINT thing which seems to be do do with window borders, and then some ERASEBKGND messages come from somewhere. I have a sneaking suspicion that the background gets erased after it's painted and not before, but that's a total shot in the dark and the absence of flicker kind of makes my theory look not so strong. Well, speaking in ignorance (I freely admit to it ;) it *could* have something to do with problem 2 of: http://www.winehq.com/hypermail/wine-devel/2002/11/0803.html corruption when dialogue boxes are moved around. I tried it again today (with cvs a few days old) and the problem still exists. Paul Millar Don't know if it helps, but I see similar corruption to Word on Painter 5. I don't know if it would help either of you guys, but I could get some traces/debug output, if someone gives me hints at to what to trace/break on. -Rob.
Chronic crash on Photoshop
Can someone look at the bug I raised about Photoshop crashing wine, (and potentially the whole of X11 and Linux) http://bugs.winehq.com/show_bug.cgi?id=1165 It's probably the most extreme bug I've seen on Linux ever. I wasn't sure if this was the appropriate place to post this request, so feel free to correct me. Cheers -Rob.
Re: Wintab.dll technical issues.
Patrik Stridvall ps-at-leissner.se |Wine Mailing Lists| wrote: Firstly a quick note: I have opened a bug for implementation of wintab.dll (Bug No. 1160) Now the questions: 1: Writing stubs. I'll be taking up Patrik Stridvall's offer to write stubs for anyone new to wine development. Yes, I'm working on it right now. Will probably not finish tonight though. One question about stubs: What's the wine policy on stub return values? Thanks for all the notes on stubs. Extremely useful. 2: Testing wintab.dll in Win98. wintab.dll is quite complex for what it does. I guess you mean wintab32.dll. wintab.dll is the 16 bit variant AFAICS. yes. wintab32.dll Always confused by both dlls being described in the wintab.h file. Therefore the only practical way to implement it is to work on the functions and communication models that are used by the apps I want it to support. Probably. To do this, I need some tool that can log the function calls and parameters to the DLL, while wunning Win98.The logging must be able to let the programmer choose elements from data stuctures in parameters/retvals to log. Any ideas There are no good tools to do this AFAIK. But if you find any I'm very intrested. I've resolved the situation by making a wrapper DLL which is tracable during debug, and will dump to file too. The winab toolkit made this suprisingly easy. It contains macros which can reduce the coding of a wrapper dll immensely. I was intending to release this logging code to the community, but I don't think it's generic enough. I've attempted to use apis32 and built a wintab.fnl file for wintab.dll. Unfortunately apis32 doen't allow the logging of the contents of data structs. Yes. APIS32 is the best AFAIK and it sucks pretty bad IMHO. Yeah, crashed my machine every time I closed it! Not going to pay $17 for something that does that. 3: Coding standards. I haven't found any coding standards associated with wine. This is particularly important, as I'll be writing new source files. Can someone point me to the standards? We have none. Decide for yourself. However please do not choose anything to unlik anything else in Wine. Or maybe many, as implied by slightly heated coding thread :-( Many thanks -Rob.
Re: Coding standards
Dimitrie O. Paun dpaun-at-rogers.com |Wine Mailing Lists| wrote: On November 25, 2002 02:38 am, Shachar Shemesh wrote: 3. Tab size should be around 3 characters. Some prefer 2, some prefer 4, but if the above guidlines are followed this should not change the correctness of rendering. Sorry, I think this is just plain wrong. Tab was always defined as being 8. Any other definition will just make code look like shit. We (the Wine ppl) almost never use 8 spaces indentation in the code. And _nobody_ uses just tabs to indent code. So all this tab rules simply has no chance in hell of working. Moreover, even if they do, they require Wine-specific editor settings which is just silly. Many times you edit things in editors you either can not control, or are not on your machine, and don't have the time and inclination to configure. Just stick to the standard: tab is 8. No mess, no fuss. Hmm Interesting comparing this to Wine code... Looking at a few odd source files from the 20020710 release, Most seemed to use 2 spece indents, no tabs. Som used 4 space indents, no tabs. I found a couple that used ~4space indent, and used tabs too (they seemed to expect 1tab = 8, as the code looked neat in a standard text editor). I found a couple with hybrid between space only indent, and what looked like tab indent wther 1tab = 4spaces. Conclusions: Tabbing is moot. I have to conclude it's not a big deal. I'll probably try to stick to spaces, and 4-space indent. I'ts clear what indent is intended, and could easily be converted to any other standard. I also don't align between lines, so an automatic tab -space conversion won't cause a problem. Brace placement: Nobody seemed to compain about this. The rules suggested by Sachar are almost a defacto standard in the industry now. What about hungarian These days I only use Hungarian for class members in C++ (m_XXX) Statics in C (s_XXX). I use type describing sparingly. The really useful coding standards are in the DEVELOPERS-HINTS file in the wine source distribution. Bye -Rob.
Re: Coding standards
David Laight david-at-l8s.co.uk |Wine Mailing Lists| wrote: A coding standard really ought to discuss namespace usage and pollution. Any reasonable layout is usually ok. (OTOH I much prefer that tab stops be at 8 character intervals.) Name space polloution, now there's something I should have thought of myself Kicking myself hard. It's been bugging me for quite a while, as I've had problems serious with namespace polloution in SQL, and C++. (It really annoys me when C++ has it's namespace polluted, because nobody uses the namespace builtin, or the namespace feature is broken in a compiler) So, What do people want to do to protect their namespaces ?? -Rob.
Wintab.dll technical issues.
Firstly a quick note: I have opened a bug for implementation of wintab.dll (Bug No. 1160) Now the questions: 1: Writing stubs. I'll be taking up Patrik Stridvall's offer to write stubs for anyone new to wine development. One question about stubs: What's the wine policy on stub return values? Should a stub always return an error? Should/Can it return success? 2: Testing wintab.dll in Win98. wintab.dll is quite complex for what it does. Therefore the only practical way to implement it is to work on the functions and communication models that are used by the apps I want it to support. To do this, I need some tool that can log the function calls and parameters to the DLL, while wunning Win98.The logging must be able to let the programmer choose elements from data stuctures in parameters/retvals to log. Any ideas I've attempted to use apis32 and built a wintab.fnl file for wintab.dll. Unfortunately apis32 doen't allow the logging of the contents of data structs. I would also like to know experinces with Spy++. Wintab can send it's own custom messages, so I'm wondering how good Spy++ is at detecting custom messages? I've used it many times before, but only to examine standard windows messages. 3: Coding standards. I haven't found any coding standards associated with wine. This is particularly important, as I'll be writing new source files. Can someone point me to the standards? Hope you guys have the answers -Rob.
Re: wintab.dll: Copyright trademark issues.
Patrik Stridvall ps-at-leissner.se |Wine Mailing Lists| wrote: As I mentioned in an e-mail a couple of days back, I'm about to start implemening a version of wintab.dll. First I want to ask about legal issues: 1. trademark issues. wintab is a trademark. Does this impact on the ability to implement wintab.dll No, I can't see how. Everything we will reasonable do with the name are either unrelated to trademarks or are used in reference to what is protected by the trademark. Which is what I assumed. Of couse I wanted to move beyond assumption. 2. API header files. Please look at the licence for the API files, avaialable at the following URL: http://www.pointing.com/Wintab/WTKIT126.ZIP Does this allow our use of the headers, in Wine? Does it allow the use of fragments of the headers in Wine? From the headers: The text and information contained in this file may be freely used, copied, or distributed without compensation or licensing restrictions. So the headers are basicly public domain. Specifically it is compatible with the X11 license and the LGPL so no problem. We could include the files as they are without any modification at all as far as copyright is concerned. Presumably we might need some compiler related fixes though. This is not too much of an issue, as I understand it's OK to re-write compatible headers In your own words. True. 3. I am in the UK, how does this affect the copyright/trademark issues above? It is not likely to matter very much almost regardless of there you are in the world, copyright and trademark laws are usually not that different. UK is pretty normal AFAIK. Ok, some background about wintab: wintab.dll is an open industry standard API developed by a group of tablet manufacturers, and seems to be currently maintained by the company LCS/Telegraphics. Web page for wintab: http://www.pointing.com/WINTAB.HTM LCS/Telegraphics home: http://www.pointing.com/LCS.HTM OK. Seem to contain documentation and other things nessary or useful for implementing. I can see two issues though. 1. It is not an offical Microsoft DLL so should it be part of Wine or not? IMHO yes, it seems to be widely used. However Alexandre decides. Interesting point. I'd like it to be part of wine. 2. How do you expect to implement this presumably very complicted DLL? Does Linux have some special libraries for supporting tablets? I was going to discuss this in some more technical e-mails, but I'll give a quick run down of the issues as I see them this minute. Initially I'll only attempt to implement enough of wintab to get it working on Painter5, and Photoshop6. To this end I'll intially only implement the features these apps require. In X11, tablets are handled by the XInput X extension. The quesiton is how to get XInput messages into the wintab format, and wintab-style of data acquisition. After that there's the question of how the dll provides the messages to it's clients. The dll also provides a lot of detail about the capabilities of a tablet. This must be at mininmum mocked up. It will eventually need some config files/registry data to map X11 info to wintab. Then there's the wintab contexts, which describe the areas of screen an app is interested in receiving messages for. These are quite compex, but I think a few assumptions may allow them to work for simple applications. The key thing is not to implement everything, and to identify subsets of the wintab features that will provide some or all of the features required by the target applications. I'll go into some more detail about the above soon. If there's anything in particular in the above that you want my thoughts on, please say. Many thanks -Rob.
Re: wm_mousehover bug fix.....
Ove Kaaven ovehk-at-ping.uio.no |Wine Mailing Lists| wrote: On 22 Nov 2002, Mike Hearn wrote: Sorry to kind of spam, it was much easier to fix it than I thought it would be. Hacking wine isn't so hard after all.. input.c line 970 should be: PostMessageA(TrackingList[i].tme.hwndTrack, WM_MOUSEHOVER, get_key_state() , (pos.y 8) + (pos.x)); More to the point, the windows headers say that for WM_MOUSEHOVER,the low 16bits contain X the high 16bits contain Y. As this stands, you have low 8 bits for X, and 24 high bits for Y. That doesn't make much sense, is the X and Y coordinates really always less than 256? Brings back memories of the the CGA days... Perhaps you meant (pos.y 16). But if so, you should probably use the MAKELONG or MAKELPARAM macro here. Sounds about right (To a windows progammer)
wintab.dll: Copyright trademark issues.
As I mentioned in an e-mail a couple of days back, I'm about to start implemening a version of wintab.dll. First I want to ask about legal issues: 1. trademark issues. wintab is a trademark. Does this impact on the ability to implement wintab.dll 2. API header files. Please look at the licence for the API files, avaialable at the following URL: http://www.pointing.com/Wintab/WTKIT126.ZIP Does this allow our use of the headers, in Wine? Does it allow the use of fragments of the headers in Wine? This is not too much of an issue, as I understand it's OK to re-write compatible headers In your own words. 3. I am in the UK, how does this affect the copyright/trademark issues above? Ok, some background about wintab: wintab.dll is an open industry standard API developed by a group of tablet manufacturers, and seems to be currently maintained by the company LCS/Telegraphics. Web page for wintab: http://www.pointing.com/WINTAB.HTM LCS/Telegraphics home: http://www.pointing.com/LCS.HTM I also found this organiation that LCS belongs to interesting: http://www.interop.org/ Many thanks -Rob.
Re: Imporving support for graphics tablets in wine (wintab.dll)
Tony Lambregts tony_lambregts-at-telusplanet.net |Wine Mailing Lists| wrote: Robert North wrote: Modern graphics tablets also provide pressure and tilt information, essential for quality graphics editors such as Painter Photoshop. Currently graphics tablets are treated as mice in wine, and so cannot provide this information to a Win16/32 app. To access pressure tilt info in Windows, a programmer would use the wintab.dll. Has anyone attempted to build a wintab.dll for Wine? In my past 3 years of monitoring this list I do not recall anyone trying to do this. I could be wrong but my memory is not all that bad... Ok, so I'll start it moving... Expect some E-mails on this list about legal and technical issues soon. I'm interested in attempting an extremely limited implementation for Painter Photoshop, but don't want to reinvent the wheel. Assuming nobody has done this what's the first step? Raise a bug, and accept it? Yup! It is not absolutly nessesary to start a bug but I would recommend it. I find it gives you a place to keep track of things and somewhere to point to if you run into problems. Another advanatage is that bugzilla maintainers such as myself can point other users to it. (if it even comes up) Ok, expect a bug to appear any time soon. Cheers -Rob.
Imporving support for graphics tablets in wine (wintab.dll)
Modern graphics tablets also provide pressure and tilt information, essential for quality graphics editors such as Painter Photoshop. Currently graphics tablets are treated as mice in wine, and so cannot provide this information to a Win16/32 app. To access pressure tilt info in Windows, a programmer would use the wintab.dll. Has anyone attempted to build a wintab.dll for Wine? I'm interested in attempting an extremely limited implementation for Painter Photoshop, but don't want to reinvent the wheel. Assuming nobody has done this what's the first step? Raise a bug, and accept it? Bye -Rob.
