I want to use HTML+CSS+JavaScript to develop a user interface for a touchscreen device in a Linux environment and need a suitable rendering engine.
The device in question will have a ARM CPU with 400 to 900 MHz clock, a VGA or WVGA display and about 256 MB RAM or more with standard Debian Linux (minimalistic install).
Ideally the rendering engine would directly access /dev/fb0 and mouse events. Since the browser is just used as a rendering engine I do not need/want any GUI - no windows, no tabs, no dialog boxes, just a single full-screen HTML page that heavily uses JavaScript to interact with the user (like a dynamic web page).
It would be great if Qt / GTK / DirectFB and such could be avoided (to reduce memory overhead and startup time) but of course this is not absolutely necessary.
Of course WebKit and Gecko come to my mind but they are both hard to understand and hard to compile. Perhaps one of the numerous forks comes close to what I need (I searched but had no luck so far)?
Ok, I think I found a valid solution myself. The standard Qt (embedded) distribution already includes the WebKit engine and writing a full-screen browser that directly draws to /dev/fb0 (no X11) is rather easy.
I will write such a (open source) browser for touchscreen devices (no mouse pointer, no borders, just the plain web page) with some JavaScript extensions for file system access, Syslog and console.log support and probably SQLite access.
Related
I'm writing a cross platform application, I want to be able to intercept keyboard input and optionally filter it from reaching the rest application. My application loads plugins, I am trying to stop the keystrokes from reaching the plugin's UI if it has focus.
On Window I use SetWindowsHookExA and on macOS I use [NSEvent addLocalMonitorForEventsMatchingMask:]
Is there an equivalent for Linux?
I'm writing a cross platform application, I want to be able to intercept keyboard input
If your application is a GUI one, consider using a cross-platform framework such as Qt or GTK (or FLTK, FOX, etc...). If your application is command-line (like e.g. grep or GCC or ninja or MongoDB are), it might not even access the keyboard, if used inside some pipeline, and you might also use cross-platform frameworks like POCO. If your software is started by crontab, it won't even have access to the keyboard, which might not even exist or be plugged in.
The same source code (for Qt or GTK or FLTK etc...) will work for Linux and for Windows.
BTW, many Linux computers (e.g. most web servers, or a RasperryPi) don't have any keyboard or mouse.
For more, read Advanced Linux Programming and syscalls(2).
Read about Xorg and Wayland.
My application loads plugins, I am trying to stop the keystrokes from reaching the plugin's UI if it has focus.
Plugins on Linux are often implemented thru dlopen(3) and dlsym(3) as ELF shared objects, conventionally in files named *.so (so see elf(5)). Read the Program Library HowTo and if you code in C++ also the C++ dlopen minihowto. If you code in Ocaml, use the Dynlink module. If you can code in Common Lisp (e.g. using SBCL), you'll just use eval. If you have to code in Java, use some class loader.
With Xorg (that is, X11) every keyboard event is generating some well defined message (some XKeyEvent) emitted - on a tcp(7) or unix(7) socket- by the Xorg server to your Xlib client application.
On the client side (in your GUI application code), an event loop (around poll(2) or select(2)...) is waiting for such messages. See also time(7).
On my Debian system (according to file /var/log/Xorg.0.log and using proc(5)...) the Xorg server is accessing the keyboard (thru udev) as /dev/input/event1 and X11 clients are communicating with the Xorg server.
I have some question about linux desktop environment.
How linux shows its desktop environment on a screen. I mean where and how its GUI frames generates and send to lcd driver? is it at kernel level? does it have any relation to frame buffer (such fb0)?
Is it possible to access the Desktop GUI of linux and write it on frame buffer to show the window environment of linux?
I have searched a lot but did not find my main answer that how linux Desktop Environment is created and shown by monitor that have been known by drivers on linux.
thank you for your attention.
In Linux there's no internal desktop or anything like that. desktop environments are just regular applications just like other applications. almost all desktop environments at their lowest level interact with another GUI library (e.g Qt, GTK, ...). then all these GUI libraries interact with lower-level software called windowing system or display server or window server.
In Unix systems most used window system is X window system ( simply called as X or X11). almost any GUI library which supports Linux, it works with X.
Wayland is another windowing system which is growing and is supposed to be a good replacement for X, because X window system is too old and have many issues. but X is used almost everywhere in Linux and other Unix based operating systems.
So if you really want to know what's going on down there, you should know linux graphics stack. as i said desktop environments are just high level applications. from windowing system (like X) to lower-level libraries and modules (KMS, DRM, ...), are what you really looking for.
KMS (kernel mode setting) works with display controller and DRM (direct rendering manager) works with graphics card and GPU. (however it's really not as simple as i explained)
I understand that in Linux a windowing system (X11, Wayland etc.) is responsible for rendering applications on the screen. I experimented with X11 but never got past obtaining single windows. I also read about Wayland. My question is, if I want to write an application that grabs whatever is shown on the screen, is there a way to get it on such a low-level (drm, dri, kms) that I am not dependent on the windowing system? What choices do these low-level APIs give me compared to the windowing system?
EDIT: I realized reading this that "One of the features of Wayland is its security design, which helps to guard the user against malicious apps. Apps can no longer see everything on the screen and spy on you. But that also means you cannot run a common application (like shutter or gtk-recordmydesktop) and use it to make a screenshot or a screencast of your desktop".
I'm experiencing graphical artifacts within Unreal Engine 4 Editor on Linux (Ubuntu 16.04, Intel HD Graphics 520 - Mesa 13.0.4). Glitches are visible in the preview window, as seen on the image pasted below:
Glitch example
I have the latest mesa drivers, installing Mesa 17.x.x is not an option, since they cause problems for the OS overall - problems with which I don't want to struggle (yet).
Running the engine with the -opengl3 flag seems to have no effect whatsoever. Example run:
Engine/Binaries/Linux/UE4Editor Absolute/Path/To.uproject -opengl3
Changing the Anti-Alias settings in Settings->Scalability does not make a difference as well.
Long story short, how can I tackle this problem? Is developing in UE4 on Linux without a dedicated graphics card possible?
In your Project Settings, you can change which rendering tech you want. It's in either General Settings or Rendering, I forget which; search for OpenGL.
As to developing on and for an in-built graphics card - Unreal will probably complain a lot, and performance will probably suffer. I think the gpu is used extensively for materials, but honestly this isn't something I know a great deal about. It would be an interesting test. You should profile your game (the profileGPU console while in-game should give a ton of information).
It's hard to know what is multithreaded in a browser and what isn't. It seems while a video streams or progressively downloads, it does not affect page performance, so my guess it is.
Note I'm using Flash video, but it's really about video in general. Any other tips on what else is multithreaded (image loads?) is also helpful. I know JavaScript is not, and I thought Flash wasn't but I heard somewhere that it may be (or it could be done), but I think they were not well informed.
flash wmode parameter controls which mode should be used. transparent runs in browser's application domain, and "window" runs as a separate flash player process drawing on width height and x&y specified by browser.
It's platform and implementation specific. With flash on the MacOS 64 bit (sorry I only know my win platform) flash runs in its own process, so definitely multithreaded. Chrome also runs all plugins on a separate thread.