Thanks.
-- Kevin
On 4/30/2024 6:41 AM, Thiago Milczarek Sayão wrote:
Hi,
I rewrote the scanner, so it's all my own code now. No legal issues
since I signed the OCA.
Generated java code looks like this:
https://github.com/tsayao/glass-wayland/blob/main/src/com/sun/glass/wayland/extracted/Xdg
Hi,
I rewrote the scanner, so it's all my own code now. No legal issues since I
signed the OCA.
Generated java code looks like this:
https://github.com/tsayao/glass-wayland/blob/main/src/com/sun/glass/wayland/extracted/XdgToplevel.java
-- Thiago.
Em seg., 29 de abr. de 2024 às 19:57, Kevin Rus
Thank you.
-- Kevin
On 4/29/2024 2:35 PM, Thiago Milczarek Sayão wrote:
I thought about possible legal conflicts.
The code is on my github - I'm exploring and testing before starting
the real work.
wayland-scanner generates code from the protocol specs, which are xml
files.
https://waylan
I thought about possible legal conflicts.
The code is on my github - I'm exploring and testing before starting the
real work.
wayland-scanner generates code from the protocol specs, which are xml files.
https://wayland.app/protocols/
I will write a new generator/scanner from scratch - it's not t
As a reminder, contributors must not include 3rd-party code in any
openjdk repo. Per the terms of the OCA, all code that you contribute to
OpenJDK must be your own code. This includes code you push to
openjdk/jfx-sandbox and code in a branch of a personal fork of
openjdk/jfx from which you crea
Hi,
I managed to display a very basic wayland toplevel surface from java:
https://github.com/tsayao/glass-wayland
If you are using intellij, just run the "Test App" (with java 22).
generate.sh will jextract the code from wayland-client.
I rushed to get the window displayed - so it doesn't look
I'm doing some work here:
https://github.com/tsayao/glass-wayland
So far it's been a good experience to use FFM / jextract.
The idea is to plug it as a glass wayland backend when it's good enough.
Em seg., 22 de abr. de 2024 às 16:16, Nir Lisker
escreveu:
> Not sure it helps with warmup, but
Not sure it helps with warmup, but marking a foreign function as critical
can improve performance:
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean)
.
On Mon, Apr 22, 2024 at 10:02 PM Philip Race wrote:
> No, it wasn't. I didn't e
No, it wasn't. I didn't even use jextracted code.
The startup cost is around initialisation of FFM - around 70 ms (IIRC)
overhead on my MacBook
Then creation of VarHandles and MethodHandles - 2-5 ms each is what I
measured, so do these lazily if you can.
And warmup cost is that it takes about 10
I think the startup time might be related to all static symbol lookups.
So I'm manually including just what is needed:
jextract --output src -t com.sun.glass.wayland.extracted \
--header-class-name GlassWayland \
`pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \
`pkg-config --c
As a reminder, using FFM will require all FX *applications* to specify
--enable-native-access on the command line
Although this is likely coming to JNI soon too.
https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
But one thing to watch out for with FFM is startup + warm up t
Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the N-1
rule.
On Mon, Apr 22, 2024 at 6:03 PM Nir Lisker wrote:
> I think that we'll be able to bump to Java 25 in JavaFX 25, like we did
> with 21. I suggested initially to bump to Java 22 exactly for FFM as it's
> very useful f
Your math is a bit off: it's 2 years from now, not 7. We recently bumped
the minimum for JavaFX 23 to JDK 21. Two years from now, we will bump
the minimum for JavaFX 27 to JDK 25.
We might consider bumping it even earlier to a non-LTS, as an exception
to our general practice, specifically to e
I think that we'll be able to bump to Java 25 in JavaFX 25, like we did
with 21. I suggested initially to bump to Java 22 exactly for FFM as it's
very useful for JavaFX, but was told we shouldn't since it's not an LTS
version.
I have no idea how long the work on Wayland will take including the cod
I was just experimenting, but it seems to be less work than going with JNI.
If I am correct, the next Java LTS will be 25, which will be required on
JavaFX 29 to be released on September/29.
It's 7 years - that's really too much.
Maybe it's still worthwhile to prototype using FFM and then port ev
Note also that we cannot use Panama in the JavaFX internals yet, since
the minimum version of the JDK is 21.
-- Kevin
On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote:
Hi,
I did a small test app to explore Wayland client and portals (for
Robot and dialogs such as file open/save).
https
Ah, yes, opaque types are indeed unsupported:
https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#unsupported-features.
As Jorn said there, if the API exposes methods that use opaque types, then
you wouldn't have a problem. Also, if you have the .c file where they are
defined, jextract can
I mailed the jextract list and Jorn Vernee explained that wayland use
opaque types, which are just defined as such:
struct wl_registry;
I guess you just pass it around and it's defined in the internal .c file.
Those are not supported by jextract.
I'll find a way to get around it.
But I've been
Can you link to where all the headers are? I found some in
https://gitlab.freedesktop.org/wayland/wayland/-/tree/main/src, but I
couldn't see where wl_registry is defined. From what I see, wl_XYZ types
are structs, which are supported.
By the way, there's a new guide for jextract at
https://github
jextract --output src -t org.freedesktop.wayland.client --header-class-name
WlClient `pkg-config --cflags-only-I wayland-client` `pkg-config --libs
wayland-client` /usr/include/wayland-client.h
WARNING: Skipping wl_registry (type Declared(wl_registry) is not supported)
I would need this to hook
What are wl_ types? jextract only supports c headers.
On Sun, Apr 21, 2024 at 10:31 PM Thiago Milczarek Sayão <
thiago.sa...@gmail.com> wrote:
> Hi,
>
> I did a small test app to explore Wayland client and portals (for Robot
> and dialogs such as file open/save).
>
> https://github.com/tsayao/way
Hi,
Been doing some experiments.
It should be possible (and the best way to go) to use wayland-client
without gtk.
Desktop iterations should be done with libportal (such as file dialogs):
https://libportal.org/
It is possible to implement the Robot with libportal "RemoteDesktop" - in
my experim
Hi,
It seems there are some opportunities to explore with Wayland:
For kiosks (Ubuntu frame):
https://mir-server.io/
https://wayland.app/protocols/
There are some interesting extensions such as Tizen (samsung OS) and
"In-vehicle infotainment": https://wayland.app/protocols/ivi-application
I foun
Hi Johan,
Robot will be a challenge.
For mouse and keyboard simulation this could work:
https://www.kernel.org/doc/html/v4.12/input/uinput.html
of maybe:
https://docs.flatpak.org/pt-br/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.RemoteDesktop
For screenshot:
https://docs.flatp
Hi Thiago,
Thanks for the work on Wayland. I spent some time on it in the past as
well, and I'll hope to find some time to look at your work soon.
The main worry I had in the past was how to deal with the robot, where we
need to get pixels from the screen -- did you tackle that?
- Johan
On Fri,
Hi,
About Wayland:
Porting es2 to use EGL instead of GLX is pretty straightforward, so
converting a X11GL* to WaylandGL* is easy (GLX is X11 only, so this is why
EGL is needed).
The problem is Gtk4 and/or Gtk3 with Wayland won't allow you to paint
directly to the window as es2 do.
I've tried to u
EGL is the way to go for Linux on Wayland and X11.
I don't know how to do it yet, but it seems the solution is to use DMABUF
with EGL and share it with GTK (I suspect on a GtkGLArea widget, but not
sure yet).
Firefox and WebKit GTK uses the same technic.
Gtk4 does not allow application painting,
Hi,
I am investigating about prism on Wayland.
It looks like we could just replace the GLX calls on X11 backend to EGL and
it will work on both (maybe rename it).
It will need some work to pass the native display around - it assumes X11
Display everywhere and it could be a Display or a wl_displa
Hi,
Update: It now works on wayland with -Dprism.order=sw
Em dom., 15 de out. de 2023 às 10:49, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:
> Hi,
>
> https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland
>
> I did some experiments here. So far, so good.
>
> 1) Replaced GDK
29 matches
Mail list logo
