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".
Related
I'll start with a little background. A small project of mine has been to try to use my Android tablet as an external monitor for my laptop using a VNC client (vnc4server). There are two main options for doing this that I have seen. The simplest is to use xrandr and widen the screen, creating a section just for the tablet. However, this can cause some graphics issues if I understand correctly, although it has the benefit of permitting windows to cross displays. The other option is to run a separate desktop session for the VNC server.
I have chosen to go the route of a second desktop as the session can live and die without significantly affecting my main session and can in theory be tailored specifically to the tablet. A little tool called x2vnc allows me to connect to the VNC server in a similar manner to the more popular Synergy and use it like a n external monitor. I also have the nice little benefit of being able to easily and cleanly switch from landscape to portrait using xrandr.
This brings me to my current issue. So far, I have only been able to reliably use plain x-windows. Although this is entirely functional, I would prefer something more complete. Although xstartup examples have been posted for a variety of window managers, none of these seem to run properly. I suspect all of these are for headless systems. Gnome/Unity are each unforgivably slow and seem to conflict with my existing session. I also feel that these are a little too cluttered for my ten inch tablet. On the other hand, Xmonad simply crashes as soon as I try to open a second window in addition to not updating the graphics properly.
I would like to know anything that will lead me in the direction of a better stable desktop environment. This includes configuration tips and alternate window managers.
I am currently running Ubuntu 12.04 with gnome-xmonad (recently Unity). My xstartup is plain x-window-manager. I have tried any readily available examples for gnome and xmonad that I have been able to find.
I want to develop a simple windows manager, but do not know which library to use. Requirements:
Take advantage of the existing high-level libraries to deal with fonts, images. Like GTK+, Clutter, GDK. But keep the design-relevance things out, which libraries should I use? Because I tried to use XCB, which is really painful. And I've heard about Wayland, and if I write it in XCB, it wouldn't be portable to Wayland.
I've read some posts on WM development, typically use XCB and Xlib, I think they are too low-level and I don't want to repeat others work. I want a more user-friendly WM, but keep simple and flexible.
The biggest issue is not the library to use. It is the complexity of the requirements, as dictated by ICCCM and EWMH.
A standard compliant window manager is quite complex, because the standards defining it are complex, and because the X11 protocol is complex.
You might fork an existing WM instead.
But any library capable of X11 protocol exchange can fit the bill.
and I am not sure that Wayland has window managers
I'd split the project in a (low-level) window manager on top of the core X11 libraries, and a high-level part implementing the UI to control the window manager, utilizing whatever toolkit you feel comfortable with.
The difficulty in using a toolkit is that these are not designed to be used from inside a window manager, i.e. the toolkit might expect to be able to send a message to the window manager and receive a reply without returning to "user" code in the middle.
Plus, this allows some more flexibility when using the window manager from different environments -- desktop integrators may choose to rewrite some of the control UI to better match the rest of the system, leaving the core service unaffected.
You can't use a high-level GUI toolkit to develop a window manager. These GUI toolkits are independent of the window manager and don't have any way to communicate directly with it - only in the ways defined by the standards.
is it possible to detect the color temperature settings of a monitor or display with css, javascript, html5, silverlight, java, flash, or anything that could be used on the web?
no problem if it's not working for all the cases, I am interested in everything.
if it is not possible right now at all, is there work in progress for this field (under what name)?
No, there isn't any way to detect this from web-based tools. In fact, there isn't really any way to detect this (in general) from a computer at all. You can change your monitor's settings all you like and your computer never knows the difference. It just sends the video signal down the cord and doesn't really care what the monitor does with it.
There is some information that goes back from the monitor to the computer, but in general color temperature is not included in that information.
However, some platforms that are more integrated, like many Apple products, may have a way to get this information from the system, but it would likely need to be a native application that has access to low-level system APIs, which most frameworks (especially web ones), including those you mentioned, tend not to have access to.
I'm looking for a really really small linux distribution or process of making my own that's sole purpose is to get an air application to launch full screen and stay there; Essentially I'm building a home kitchen computer that runs entirely as an AIR app.
I have looked into using windows xp; and windows xp embedded but they pose so many issues I figured I'd try modern linux.
I have also seen TinyCore Linux which looks interestingly small but not sure what issues that poses in regards to running AIR and "hardware" accelerated display. I've also thought about stripping down an Ubuntu installation but I'm sure somebody must have done this already; google is just failing me right now...
I'm also interested in running an "embedded" version of say android and running the air app on some arm-based hardware again; with just the AIR runtimes only - although this is less preferred as it's more complex.
I'm also hooking this up to a touch screen monitor (not yet arrived) so I'll need to hunt down or write some drivers for translating the touch events into something AIR can understand... (this was my main intention for using windows in that all the drivers will just work).
What I'm after
Minified Linux kernel with JUST the drivers for the box I need
X Display with accelerated graphics support (Doesn't have to be X if AIR can run on a frame buffer?)
Running a Full screen AIR application (simple enough)
Ability to write back to the filesystem (enough support for AIR)
SSH Access for remote control
Samba for updating the filesystem (easier to maintain the system)
Touch screen support (3M Ex III I think...)
Audio support
Don't need
Don't need any window manager or any other GUI tools unless required by AIR
Don't need any toolbars or file managers or anything; The AIR app is the "OS"
Don't need any package managers or repos
Don't need multi user or logging in; everything can just run as an unprivileged account
Don't need to
I don't mind hand crafting the filesystem and configs if that makes it easier; I'm mainly looking for a "filesystem" that is as tiny as possible that I can just plop my AIR app into and write some scripts to get it to start when the X server starts
Thanks,
Chris
Try an embedded Linux build system such as Buildroot. It can build an entire system from source, and be very lightweight. The basic system is less than 1 MB in size.
Ended up going with Tiny Core. Very tiny and quick to boot up. You can also write extensions for it and you don't have a persistent drive which allows you to just switch the thing off without worry that it's going to break something -- exactly what you need in a kitchen :-D.
My current plan is to:
Just set up a working version using Ubuntu as this is mostly supported by Adobe
Slowly strip it back and try and get as little things to start as possible on boot
Try building my own distro/package from source and selecting only the packages I need
Compile my own kernel with nearly everything turned off and just leave on the things I need
I recently started using Linux (where I work is a Microsoft shop, so I only code in C#, work with MS products etc).
I'm trying to understand at a high level how some basic things in Linux hang together.
I've been reading www.linfo.org
Anyway I've never quite got what X is.
From reading this article it seems to me that X is layer that sits on top of the operating system (one X server sitting on top of the OS??) and X client applications make requests to the X server.
I think KDE, Xfce and Gnome are display managers, are they X server clients then?
I'm quite confused where everything sits.
Any explanation would be really appreciated!
It's all very modular and flexible; however this leads to complexity.
The "X Server" drives the display device. It provides graphics services to clients, and those services are pretty simple - such as:
"Give me a window frame to draw in"
"Put this bitmap here"
"Draw a horizontal black line 100px wide"
"Render the text 'hello' at (100,100)"
"Tell me if any mouse clicks or key presses have been aimed at my window frame"
There is a library called Xlib, provided by X, that has a standard interface for all these simple services. Any program that wants to use the X server's display eventually uses this client library and is called an X Client. Xlib knows how to connect to an arbitrary X server - on the local machine, or via TCP/IP across the LAN, or across the world - to call these services.
The Window Manager, which is just another X client program, is in charge of the "look and feel" of the desktop - how you move and arrange windows, etc. Because the window manager draws all the window decorations, it can make the desktop look like WindowsXP, or a Mac, or NeXTSTEP.
Part of the philosophy of X was to define "mechanism and not policy" - meaning, they give you tools to do it, but don't tell you how to use those tools. One such tool is the window manager, which can be replaced at will.
Many modern X applications are written to use a desktop enviroment such as Gnome or KDE. This offers these programs a consistent set of buttons and controls to draw, and a consistent interface for some things not traditionally included in X, but often considered part of a desktop - such as how to respond to drag-and-drop or how to present a standard file chooser dialog box.
The desktop environment usually provides an object model or programmatic interface that takes care of making all the simple X client requests and lets the program handle more important things. Removing these low-level calls yields another important benefit - platform independence.
Many desktop environments include a window manager, so that the look and feel of window controls and buttons is consistent and works with the desktop metaphor provided by the environment. However, it can usually still be switched out.
The separation of the X Server (running the display) and the X Client (wanting to use the display) has a few implications:
The graphics system is separate from the GUI programs, and they are separated about as completely as a web browser and web server are.
So the GUI program might not be displaying on the local machine - just like a web browser doesn't have to point at a web server on the local machine.
A machine can run JUST the client, with the X server elsewhere.
The machine with the display doesn't have to run the client - it can run JUST the X server, and all the clients can run on a dedicated machine. This is the original thin client: big programs running on big central server - with graphical user interaction handled by dedicated hardware on the desk in front of the user.
You need to know what your X server's network address is so you can tell GUI programs where to display their GUI. (this is usually done by setting the DISPLAY environment variable)
You can display many programs, from many different machines, all on the same desktop at the same time. It is all handled seamlessly, including cut-and-paste.
X11 is a network protocol, currently at release 7 (hence X11R7). It encapsulates graphics and input information, and connects an X client (application or window manager) running on a local or remote machine to the X server currently driving the local screen and input devices.
Gnome, KDE, XFCE, and LXDE are desktop environments; they contain pieces that talk to/with the X server (metacity, kwin, etc.), but also consist of specifications that applications must follow and libraries that are available in order for an application to "belong" to the DE.
In addition, it's worth remembering that the X server is just another program that gets run under linux. There's nothing special about it, it just happens to know how to grab onto the graphics card and take over the monitor using video drivers.
You can (theoretically) run linux very happily without ever running an X server - although of course, you would be limited to the command line programs.
That's how linux organises itself - kernel at the base, then a set of programs that provide functionality to higher level programs, which themselves provide functionality to higher level programs, all building up into a complete stack of software oriented to whatever the job of the machine is (say, general desktop, software development, web server, etc).
Beyond the kernel and it's modules, nothing is 'special'.
Wikipedia has some info about it.