How to call an internal wine function ?

Open forum for end-user questions about Wine. Before asking questions, check out the Wiki as a first step.
Forum Rules
Locked
Alex
Level 2
Level 2
Posts: 35
Joined: Fri Jul 11, 2008 10:50 am

How to call an internal wine function ?

Post by Alex »

First off, I know that there is a devel mailing list but I really prefer using forum. I guess I'ma kind of 'user++' ie a user with some basic coding knowledges.

Whatever I am, I think anyone wanting to help wine is welcome so here I am.


I would like to call X11DRV_VkKeyScanEx function but the linker does not know where to find it.

I have a dlls/winex11.drv/winex11.drv.so file but adding '-L PATH_TO_X11DRV -I PATH_TO_X11DRV' to winegcc does not solve the problem.

Should I include a specific header ?
The x11.drv.spec file contains a line defining the function but I never used these files.

Some help would be greatly appreciated.
Thanks in advance
vitamin
Moderator
Moderator
Posts: 6605
Joined: Sat Feb 23, 2008 2:29 pm

Re: How to call an internal wine function ?

Post by vitamin »

Alex wrote:I would like to call X11DRV_VkKeyScanEx function but the linker does not know where to find it.
Don't call it directly. You should be calling VkKeyScan* api functions from user32 instead.
Alex
Level 2
Level 2
Posts: 35
Joined: Fri Jul 11, 2008 10:50 am

Post by Alex »

Thanks for your answer but VkKeyScan* functions do not behave exactly as M$ ones (leading to a crash in my software but that's another problem) .

I tried to look at +relay,+keyboard,+key log but I still does not understand what's wrong (²).

If I could call them, I think the issue would be easier to find.

But you're maybe a 'real' developer who knows a better approach...

---
² : +trace does not trace internal functions so I can see LoadLibrary call with winex11.drv as parameter but not X11DRV_VkKeyScanEx one which is a bit frustrating when you want to understand what's going on internally
vitamin
Moderator
Moderator
Posts: 6605
Joined: Sat Feb 23, 2008 2:29 pm

Post by vitamin »

Alex wrote:Thanks for your answer but VkKeyScan* functions do not behave exactly as M$ ones.
You filed a bug for that in bugzilla?
Alex wrote:I tried to look at +relay,+keyboard,+key log but I still does not understand what's wrong :
+trace does not trace internal functions so I can see LoadLibrary call with winex11.drv as parameter but not X11DRV_VkKeyScanEx one which is a bit frustrating when you want to understand what's going on internally
I'm not sure what you looking for but here is how it works. For example, if you look at VkKeyScanExW(): http://source.winehq.org/source/dlls/us ... put.c#L587 you'll see it's calling the USER_Driver which is x11drv on Wine and the actual implementation of that functions is, as you said it, X11DRV_VkKeyScanEx.
Alex wrote:But you're maybe a 'real' developer who knows a better approach...
Yeah I'm a developer. Aside from wanting to call something you shouldn't be calling directly you haven't said what's the problem.
Alex
Level 2
Level 2
Posts: 35
Joined: Fri Jul 11, 2008 10:50 am

Post by Alex »

You filed a bug for that in bugzilla?
Yeah, it's this bug.

But I know there are lots of bugs and mine is (even if annoying) not critical.

So I thought "Hey, Alex ! Why don't you try to understand how it works ? Thus, you could fix this issue on your own !"

I'm not sure what you looking for but here is how it works. For example, if you look at VkKeyScanExW(): http://source.winehq.org/source/dlls/us ... put.c#L587 you'll see it's calling the USER_Driver which is x11drv on Wine and the actual implementation of that functions is, as you said it, X11DRV_VkKeyScanEx.
I understood that but if I can't call it directly, I have to modify the source, adding some printf() or TRACE_(alex) and compile it again.

But there is not problem, I'm here to learn, so thank you again.
vitamin
Moderator
Moderator
Posts: 6605
Joined: Sat Feb 23, 2008 2:29 pm

Post by vitamin »

Alex wrote:Yeah, it's this bug.
That bug is due to that symbol [#] not being present on Wine's keyboard layout (see main_key_FR array in winex11.drv/keyboard.c). Do you know which key is it on? I couldn't find it when setting my layout to FR.
Alex
Level 2
Level 2
Posts: 35
Joined: Fri Jul 11, 2008 10:50 am

Post by Alex »

The '#' char is present on the '3' key and '~' is on the '2'.

But should should have a look at this from azerty keyboard entry on fr.wikipedia

English version of wikipedia have a colored version but it's the same. :roll:
vitamin
Moderator
Moderator
Posts: 6605
Joined: Sat Feb 23, 2008 2:29 pm

Post by vitamin »

Alex wrote:The '#' char is present on the '3' key and '~' is on the '2'.
Looks like a bug in Xorg's key layout table(s) or Xorg itself. XKeycodeToKeysym(,0x12, index) should return 0x23 at least for one index (0..3). But it doesn't. Here is what xmodpap says:

Code: Select all

$xmodmap -pk | grep numbersign
     12         0x0022 (quotedbl)       0x0033 (3)      0x0022 (quotedbl)       0x0033 (3)      0x0023 (numbersign)     0x00a3 (sterling)
$xmodmap -pm
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)
Which means "#" sign is outputted with modifier "mod4". Not exactly sure how that "index" maps to modifier. But Wine gets AltGrMask as 0... You can look around and see if this is all correct. Could be some mapping/logic error somewhere.
Alex
Level 2
Level 2
Posts: 35
Joined: Fri Jul 11, 2008 10:50 am

Post by Alex »

Well, I am still learning but what I understood is that when you press the key of keycode 12 (as xev says) with

noting -> "
shift -> 3
lock -> "
? -> 3
mod4 ie AltGr -> #
? -> (sterling)

So we're expecting to find the keysym 0x0023 from the keycode 12 with the 'mod4' pressed.

If you compile this sample :

Code: Select all

#include <X11/Xlib.h>
#include <X11/keysymdef.h>

int main()
{
        int i;
        KeySym keysym;
        Display *display = XOpenDisplay(NULL);

        if (!display)
        { printf("err\n"); return 10; }

        for( i=0; i<9; i++)
        {
                keysym = XKeycodeToKeysym(display,12,i);
                printf("%d_%lX_\n", i, keysym);
        }

        XCloseDisplay(display);

        return 0;
}
you should get

Code: Select all

gcc test.c -lX11 && ./a.out
0_22_
1_33_
2_22_
3_33_
4_FE55_
5_0_
6_FE55_
7_0_
8_33_
but indeed, there is no 0x0023.

I tried with 1000 instead of 9 but the following lines are '0'.

Please note that I have never used any XLib function before, so maybe I'm misunderstanding what I'm doing.
vitamin
Moderator
Moderator
Posts: 6605
Joined: Sat Feb 23, 2008 2:29 pm

Post by vitamin »

Alex wrote:Please note that I have never used any XLib function before, so maybe I'm misunderstanding what I'm doing.
No, the sample code is correct. This is definitely something wrong with X or more likely it's keyboard layout tables.
Alex
Level 2
Level 2
Posts: 35
Joined: Fri Jul 11, 2008 10:50 am

Post by Alex »

I found this bug on freedesktop bugzilla.
I added two testcases hoping they will fix it.

But even if they solve it now, we will have to wait the next version , wait that every one update their computer and run the latest version.

However, I'm glad to help linux to get working better :roll:
Locked