OK, I'll push this for you.

-phil.

On 7/31/19, 6:18 PM, Ichiroh Takiguchi wrote:
Many thanks, Phil.

I just became committer.

Can someone help me push the fix [1] to avoid some mistakes in urgent situations ?

I really appreciate your help.

[1] https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.02/

Thanks,
Ichiroh Takiguchi

On 2019-08-01 09:47, Philip Race wrote:
OK I approved it and you are good to push.

-phil.

On 7/31/19, 5:34 PM, Ichiroh Takiguchi wrote:
Thanks Phil and Vladimir.

I just put fix request into 8227919 [1] against JDK13.

[1] https://bugs.openjdk.java.net/browse/JDK-8227919

Thanks,
Ichiroh Takiguchi

On 2019-08-01 02:45, Phil Race wrote:
Ok, that looks a lot more sane.

You (Ichiroh) will need to follow the JDK 13 fix request process here :
http://openjdk.java.net/jeps/3#Fix-Request-Process

An example of a recent case is https://bugs.openjdk.java.net/browse/JDK-8217676

Also remember you fix this ONLY in JDK 13.
The fix will be forwarded synced by integrators here into JDK 14.

-phil.

On 7/31/19 8:40 AM, Vladimir Kempik wrote:
Hello

In fact such minimalistic change only affects code generation on solaris sparc64

We have tested such fix on openjdk-11.0.4 with solaris sparc64 and it passed tck just fine.

Vladimir.

31 июля 2019 г., в 16:43, Ichiroh Takiguchi <taki...@linux.vnet.ibm.com> написал(а):

Hello Phil.

I appreciate your comment.

Just in case, I created another fix.
It's Vladimir's idea.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8227919
Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.02/

Just added "defined(__linux__)"

I think it can minimize the side effect for OpenJDK testing.
I'll open another bugid for Linux s390x issue.

I'm not sure which is the best or better on this situation...

Thanks,
Ichiroh Takiguchi

On 2019-07-31 05:23, Phil Race wrote:
Hi,
I've stared at this fix and all this bit shifting inside ifdefs is
hard to believe
this is the way you have to use XIM.
Also JDK 13 testing is already well under way and a lot of the testing for Linux has already been finished. So *you* are going to have to run (1) all regression tests on Linux & Solaris and that there are no new failures (2) JCK on Linux and Solaris and certify it all passes else we could have a DOA release or
a release stopper.
I think given that, and my observations about the fix I think that the safe option for JDK 13 is to completely back out 8213232 and try again
for JDK 14.
But even then I'm first going to want to see pointers to documentation
for XIM which
say why what you are doing is correct.
-phil.
On 7/30/19 10:02 AM, Ichiroh Takiguchi wrote:
Thanks, Vladimir.
I think it's urgent issue for JDK13.
Another reviewer is required.
And I'd like to obtain a sponsor for this issue.
Thanks,
Ichiroh Takiguchi
On 2019-07-29 21:49, Vladimir Kempik wrote:
Looks good to me.
Now need some reviewers to take a look at it.
Thanks, Vladimir.
29 июля 2019 г., в 15:44, Ichiroh Takiguchi <taki...@jp.ibm.com> написал(а):
Hello Vladimir.
I appreciate your suggestion.
And I'm very sorry for bad response.
Our mail server for external mailing list is downed in these days.
So I'd like to use another email address.
Please see following 2 outputs.
$ XMODIFIERS=@im=local ./xim_root
......
ButtonPress:
[1]w=0x2000002
[2]w=0x2000002
[1]state=0x2
[2]state=0x2
$ XMODIFIERS=@im=kinput2 ./xim_root
......
ButtonPress:
[1]w=0x200000200000000
[2]w=0x2000002
[1]state=0x200000000
[2]state=0x2
These mean
@im=local is used low 32bit on 64bit long <= The data comes from Xlib @im=kinput2 is used high 32bit on 64bit long <= The data comes from XIM
protocol
So following code changes is required on Linux s390x, it was my mistake.
if (w > 0xffffffffUL) w = w >> 32;
I created another fix, could you review it ?
Bug:    https://bugs.openjdk.java.net/browse/JDK-8227919
Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.01/
It changes:
* 0xffffffffL is changed to 0xffffffffUL
* defined(__linux__) is added into defined(_LP64) line
Thanks,
------
Ichiro Takiguchi
    IBM Japan Ltd.
"awt-dev" <awt-dev-boun...@openjdk.java.net> wrote on 2019/07/26 21:59:59:
From: Vladimir Kempik <vkem...@azul.com>
To: Ichiroh Takiguchi <taki...@linux.vnet.ibm.com>
Cc: "awt-dev@openjdk.java.net" <awt-dev@openjdk.java.net>, "i18n-
d...@openjdk.java.net" <i18n-...@openjdk.java.net>
Date: 2019/07/26 22:01
Subject: [EXTERNAL] Re: <AWT Dev> RFR [13] 8227919: 8213232 causes
crashes on solaris sparc64
Sent by: "awt-dev" <awt-dev-boun...@openjdk.java.net>
Hello
what still bothers me is this:
The first Big Endian block:
1629 #if defined(_LP64) && !defined(_LITTLE_ENDIAN)
1630         // On 64bit BigEndian,
1631         // Window value may be stored on high 32bit by
XGetICValues via XIM
1632         if (w > 0xffffffffL) w = w >> 32;
1633 #endif
is inside linux&macos block
1622 #if defined(__linux__) || defined(MACOSX)
however the second Big Endian block is for every platform:
1698 #if defined(_LP64) && !defined(_LITTLE_ENDIAN)
1699     // On 64bit BigEndian,
1700 // XIMPreeditState value may be stored on high 32bit by
XGetICValues via XIM
1701     if (state > 0xffffffffL) state = state >> 32;
1702 #endif
I?m not sure if it?s ok or not.
Also, since XIMPreeditState is unsigned 64-bit int, I think we need
to compare it against 0xffffffffUL instead of 0xffffffffL
typedef unsigned long int XIMPreeditState;
Thanks, Vladimir
26 июля 2019 г., в 15:53, Ichiroh Takiguchi <taki...@linux.vnet.ibm.com
написал(а):
Hello.
Could you review the fix ?
Bug:    https://bugs.openjdk.java.net/browse/JDK-8227919
Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.00/
It's crash issue for Solaris SPARC platform.
If possible, please push this fix into 13.
XIMPreditState is changed to unsigned long instead of unsigned int
on 64bit Big endian.
It's same as Java8.
I think Solaris SPARC's issue can be fixed by this fix.
Vladimir,
I appreciate your great help.
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
On 2019-07-23 20:00, Vladimir Kempik wrote:
Hello
it still crashes with  "Bus Error"
I guess I may miss something on X server side.
Thanks, Vladimir.
22 июля 2019 г., в 21:08, Ichiroh Takiguchi <taki...@linux.vnet.ibm.com
написал(а):
Hello Vladimir.
I really appreciate your help.
"XMODIFIERS=@im=local" is related Multi key Compose feature [1]
One of document said "XMODIFIERS=@im=none" [2]
Could you try "XMODIFIERS=@im=none" ?
[1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml < https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml>
[2] https://fedoraproject.org/wiki/I18N/InputMethods <https://
fedoraproject.org/wiki/I18N/InputMethods>
Thanks,
Ichiroh Takiguchi
On 2019-07-22 23:58, Vladimir Kempik wrote:
Hello
I?m getting Bus Error on startup with
XMODIFIERS=@im=local ./xim_root
nothing yet in log at that moment.
Thanks, Vladimir
22 июля 2019 г., в 15:12, Ichiroh Takiguchi <taki...@linux.vnet.ibm.com
написал(а):
Hello Vladimir.
I appreciate your reply.
I did not expect "[1]w=0x0", it means xim_root could not receive
focus window via XIC.
I checked ibus XIM server on Linux s390x platform again, it also
returned "[1]w=0" ...
I was confused.
I'd like to add new instruction
5. Run xim_root with XMODIFIERS=@im=local environment variable on
desktop, like
$ XMODIFIERS=@im=local ./xim_root
6. Move input focus to XIM demo window
7. Press Ctrl key and Press Right mouse button
I tested xim_root on Linux s390x platform.
$ XMODIFIERS=@im=ibus ./xim_root
fevent = 0x3
topwindow = 0x1e00001, window = 0x1e00002
ClientMessage is received
WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945
XSetInputFocus() is called
FocusOut: window=0x1e00002(Internal Window)
XUnsetICFocus
FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit)
FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit)
FocusIn: window=0x1e00002(Internal Window)
XSetICFocus
KeyPress:
ButtonPress:
[1]w=0x0
[2]w=0x0
[1]state=0x0
[2]state=0x0
State: Unknown
ClientMessage is received
I tried it with XMODIFIERS=@im=local
$ XMODIFIERS=@im=local ./xim_root
fevent = 0
topwindow = 0x2000001, window = 0x2000002
ClientMessage is received
WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372
XSetInputFocus() is called
FocusIn: window=0x2000001(XIM demo - root-im window - 64bit)
FocusIn: window=0x2000002(Internal Window)
XSetICFocus
KeyPress:
ButtonPress:
[1]w=0x2000002
[2]w=0x2000002
[1]state=0x2
[2]state=0x2
State: IM Off
ClientMessage is received
I was expected this result.
$ XMODIFIERS=@im=kinput2 ./xim_root
fevent = 0x3
topwindow = 0x2000001, window = 0x2000002
ClientMessage is received
WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128
XSetInputFocus() is called
FocusIn: window=0x2000001(XIM demo - root-im window - 64bit)
FocusIn: window=0x2000002(Internal Window)
XSetICFocus
KeyPress:
ButtonPress:
[1]w=0x200000200000000
[2]w=0x2000002
[1]state=0x200000000
[2]state=0x2
State: IM Off
ClientMessage is received
I'm sorry, it seemed current code did not work on even if Linux
s390x platform.
Thanks,
Ichiroh Takiguchi
On 2019-07-19 23:29, Vladimir Kempik wrote:
Hello
I?m probably missing something about XIM on X side here, using ssh
-X from ubuntu(with Xserver) to solaris11 sparc64 machine
the output is
fevent = 0x3
topwindow = 0x3800001, window = 0x3800002
ClientMessage is received
WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503
XSetInputFocus() is called
FocusIn: window=0x3800001(XIM demo - root-im window - 64bit)
FocusIn: window=0x3800002(Internal Window)
XSetICFocus
FocusOut: window=0x3800002(Internal Window)
XUnsetICFocus
FocusOut: window=0x3800001(XIM demo - root-im window - 64bit)
ClientMessage is received
WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238
XSetInputFocus() is called
ButtonPress:
[1]w=0x0
[2]w=0x0
[1]state=0x0
[2]state=0x0
State: Unknown
FocusIn: window=0x3800001(XIM demo - root-im window - 64bit)
FocusIn: window=0x3800002(Internal Window)
I also had to press left button, not right one.
I think when you initialy created 8213232 you were targeting linux ppc64 BE system in your patch and simply forgot about another 64-bit
BE system - solaris sparc64
I would propose this fix for 8227919
--- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
@@ -1671,7 +1671,7 @@
{
  X11InputMethodData *pX11IMData = NULL;
  char * ret = NULL;
-#if defined(_LP64) && !defined(_LITTLE_ENDIAN)
+#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) // XIMPreeditState value which is used for XGetICValues must be
32bit on BigEndian XOrg's xlib
  unsigned int state = XIMPreeditUnKnown;
#else
Such change already allowed to pass our internal tests on solaris
sparc64
if you think it?s ok then let me take over and finish with 8227919
Thanks, Vladimir
19 июля 2019 г., в 16:57, Ichiroh Takiguchi
<taki...@linux.vnet.ibm.com <mailto:taki...@linux.vnet.ibm.com> < mailto:taki...@linux.vnet.ibm.com <mailto:taki...@linux.vnet.ibm.com>>< mailto:taki...@linux.vnet.ibm.com <mailto:taki...@linux.vnet.ibm.com>< mailto:taki...@linux.vnet.ibm.com <mailto:taki...@linux.vnet.ibm.com>>>>
написал(а):
Hello.
I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1]
Please follow the steps:
1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC
2. Run xim_root on desktop
3. Move input focus to XIM demo window
4. Press Ctrl key and Press Right mouse button
Please put the output into JDK-8227919 [1] or post it into mailing list.
I really appreciate if you are using XIM like IIIMF.
[1] https://bugs.openjdk.java.net/browse/JDK-8227919
[2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c
Thanks,
Ichiroh Takiguchi

Reply via email to