How to call an internal wine function ?
How to call an internal wine function ?
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
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
Re: How to call an internal wine function ?
Don't call it directly. You should be calling VkKeyScan* api functions from user32 instead.Alex wrote:I would like to call X11DRV_VkKeyScanEx function but the linker does not know where to find it.
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
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
You filed a bug for that in bugzilla?Alex wrote:Thanks for your answer but VkKeyScan* functions do not behave exactly as M$ ones.
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: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
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 wrote:But you're maybe a 'real' developer who knows a better approach...
Yeah, it's this bug.You filed a bug for that in bugzilla?
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 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.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.
But there is not problem, I'm here to learn, so thank you again.
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 wrote:Yeah, it's this bug.
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.
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.

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:Alex wrote:The '#' char is present on the '3' key and '~' is on the '2'.
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)
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 :
you should get
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.
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;
}
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_
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.
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
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
