This is one of my coding projects. I'm fairly new to linux, so I need some pointers and thoughts from you guys, before I get started. I know there exists screen sharing software already, but I want to make my own! (=
Specifically, I want to clone my laptop screen to my TV over WLAN, via a linux box that is connected to a TV through a VGA cable:
Laptop streams it's screen
Linux box reads the stream
Linux box outputs the stream into the TV (through a VGA cable)
First of all, how do I record the screen and send the stream in real time in linux?
Secondly I must write a program that reads the stream being sent. The program must listen to some port, and collect the data being streamed from the laptop. Any thoughts?
Then I must output that data in real time to the TV. Do you how any ideas on how to solve this?
Thanks!
Edit: Regarding programming languages, I'm most comfortable with python.
Sharing your screen can be done via the various flavors of VNC (ie. RealVNC, TightVNC, UltraVNC, etc.). Most of them are Open Source, you might want to:
Stick with the VNC protocol for later compatibility
Take example of how the established solutions does for screen-hooking.
In Linux, the graphics are all processed by Xorg (new version of X Server), which was developed with networking embedded. This explains why you can ssh -X into a machine, execute a graphical interface on it and see it on your remote computer. I recommend you to read about hooks on Xorg to achieve your needs.
You need a client-server topology to achieve your needs. You are not talking about any programming language you forecast to use, though. Some languages may be harder than some to start with. Furthermore, this kind of code is already really well understood under every major programming language. You should try to at least use a framework that simplifies your networking portion of the project.
Sharing a screen on the TV can be done by your video card driver in Linux. Just check on your Desktop Environment (KDE and Gnome offers video configuration panels, for example) or in your video card configuration (nVidia and ATI Linux drivers offers multiple screen support)
It seems to me like you're trying to reinvent the wheel and are not too sure about how to begin. I recommend you to begin simple with one of the already proven VNC software and see how it goes from there. If a feature is missing, you've got the source code of the server and the client, so you can continue development of these projects. Once you've got your setup working, start thinking about replacing a single piece of the puzzle by your own code, and see how it goes.
Do not expect good (full HD, for instance) video quality on your TV without some very capable CPU/GPU and a 802.11n wireless network empty of users and be ready to accept some lag for the codecs to kick in.
You should try to take as small steps as possible. If I were taking up such a project, my first step would be to try to implement a solution using standard unix tools (e.g. netcat or socat for the network part, mplayer or vlc for the playback and maybe ffmpeg for the capture)? Then, replace each component with custom-written ones if needed.
was wondering - if knowing The Linux way of life or the Linux architecture, would give a better frame of mind for programming on embedded devices especially when they have some kind of OS in them.
Just want to be sure that I did not miss a major thing :)
Note:
I come from a windows background, can program in C and C++.
Passionate and finally want to get started into Embedded programming. I would like to start by doing typical hobbyists project at home.
It would be nice if anyone would also comment on BeagleBoard as a starting point for me.
"Embedded" is a fuzzy word. There are two categories:
There are realtime embedded systems: microcontroller/microprocessor applications that are intimately communicating directly with the hardware on a low abstraction level. Typical applications are control systems/automation, industrial, automotive, medtech, household electronics, data/telecom communications etc.
And then there are fluffy embedded systems: various laptop:ish computers, embedded linux, embedded windows, phones and phoney operative systems, anything involving internet, human-machine intefaces etc.
People working in both categories will firmly state that they are working with embedded systems, while the latter kind are often just doing another flavour of desktop applications. Depending on which category you are aiming for, Linux may or may not be a merit. The telecom branch for example, overlaps both of these categories, and they are often using embedded Linux even for non-fluffy applications.
In either case, *nix may be used as the development platform, so knowing it won't hurt.
Yes and no. Mostly yes.
Lundin correctly described the "two worlds of embedded" (although the border between them is very fuzzy).
If you're writing for "higher embedded", like Android, or other devices that run Linux, then definitely expert knowledge of Linux will be of much help. You still need to know some "bare bones" and don't get scared when you see the likes of &=~ operator in C, but knowing Linux - the Linux of the old, where you configured stuff by editing files in /etc, where you compiled your own kernels for everyday use, where you would build software from tarballs, that's what helps. Knowing modern Linux - Gnome, gconf-editor, Synaptic and the likes will not be of much help.
Then next, if you're programming devices without OS, in the middle area - fast and strong enough to run C programs, but not the OS, you still need Linux. Because crosscompile. You don't need actual Linux. Cygwin is okay for that. MinGW may suffice. Still, you will probably need to be able to build your own crosscompiler (based on GCC), linker, debugger, make tools, and the rest of "backbone" of the IDE. Unless your chip supplier is awesome and provides a complete toolchain with IDE.
Only when you're into tiny processors, you don't need Linux. Stuff like car alarm remote, christmas lights blinker, car tire pressure sensor, battery level monitor - stuff that can have 16 bytes RAM, 1KB EEPROM, and the rest of CPU to match, you will need to use an IDE that works with this CPU, no OS, no C compiler, nothing remotely close to Linux - the IDE will most likely be Windows based.
I'd say you really do not need to know Linux for embedded programming. Many companies developing embedded software do it on windows and have no contact with other OS.
But sure, knowing more makes you more versatile, and general knowledge makes you a better engineer. This includes different OS as many other things.
When it comes to BeagleBoard, it depends on the kind of application you are interested in.
If you want to understand the low-level, I would start on a simpler processor and learn how to use peripherals, hardware interrupts, debouncing signals... There is an educational point in doing this yourself some time.
I suppose you can also skip that and start with an ARM-A8 and possibly an embedded OS, it's just not the path I followed.
What I am about to say may cause a flame war, but...
I have found that Linux is a much more productive development environment than Windows. At my previous job, we were developing firmware for managed switches and industrial automation equipment, which ran an embedded Linux operating system. All the developers had both Windows and Linux boxes, as the user interface software only ran on Windows. We all used Linux for developing, though, as it was simply easier.
At my current job, the only choice is to run Windows, but to make it more productive we are running Cygwin, which provides a Linux-like environment. It is very difficult to develop software on Windows that is not specifically for Windows.
As for developing for an embedded system without an OS... I have an Arduino that I play with occasionally. I have programmed it both from Windows and Linux, and have found the experiences fairly similar. Using Arduino's own tools, Windows seems to run a bit more smoothly, but if you want to hack on it and make something interesting, you're better off using Linux.
Personally (and this will likely provoke some nasty comments), I feel that Linux is best for doing productive work, and Windows is best for playing games.
So basically, this all boils down to this: Try using Linux for developing your project. You will probably find it to be a much smoother, more productive experience. If you don't like it, you don't have to keep using it. But the experience will probably be worth it.
Edit (due to question rewording): Knowing the "Linux way of life" is unlikely to help much when coding for an embedded project that is not running Linux itself. As I understand it, the Unix philosophy is about two main issues:
Each tool should do one thing and do it well (don't make something that tries to be everything).
Whenever possible, data should be plain text (allows for simple piping through processes and searching for content).
If you are working on a system without an operating system, you are writing code for a compiler and not likely working with a full shell at any point. You also are unlike to have any sort of file system. So both of these points are moot; you are not likely to gain anything concretely related to embedded programming by studying Linux, although it certainly couldn't hurt :-)
I really think if you want to learn a little about embedded sphere you should not start by using an OS directly. Prefer to have hands on a small low level project then add an OS if it's really needed for your final application.
I don't think setting up an OS into an embedded device will be easier than starting from scratch. It will bring you some functionalities (that I am not sure you really need to learn embedded) but it will bring you lot of hard debugging time in case of problems in the OS port.
I have been doing embedded programming for 10 years, currently for networking equipment and before that Apache helicopters. Both companies had POSIX-like operating systems on the target, but not embedded Linux directly. My current company uses mostly Windows for individual developer environments. However, we do have a few Linux boxes hanging around for special purposes. My previous company used a mix of Windows and Sun Solaris Unix. So wherever you go, you may not use Unix or Linux on your day to day computer, but you are likely to come across it at least occasionally.
On the other hand, I've known developers who have programmed on Linux for embedded Linux targets their entire careers. It really depends on the company, as smaller or newer companies have a tendency to use Linux more than corporations. However, using embedded forms of Windows on targets is very rare in my experience. I know devices are out there, but I've never personally met a developer who worked on one.
Anyway, Linux is free to use and has other benefits besides being good for a job. There's really no downside to giving it a try for a couple of months, other than giving up some of your time.
Linux is growing in embedded... see latest research:
Top 10 trends for the embedded software and tools market in 2011 - VDC research
Android Becomes Number One in U.S. Smartphone Market Share
Knowing the Linux way of life will definitely be a plus in embedded domain provided the kind of apps you are interested in are contained in the above mentioned links.
understanding Linux architecture will be over kill (although basic overview is good) before just starting in embedded field
e.g. to cut a tree you don't have to invent an axe - just start using one, then gradually you could learn to sharpen the axe
Its better to get started small - get hands-on, and focus on specific areas as is the need of the hour. grow with your work and work keeping your goals in mind
you will surely gain much faster and not get stuck in self loop - R&D to do R&D ;)
Only if you want to embed Linux! And as an embedded systems developer of some 22 years, I would suggest that Linux is unsuitable and unnecessary for a very large proportion of embedded systems projects.
Understanding the workings of an RTOS, and real-time priority based pre-emptive scheduling and IPC mechanisms would stand you in better stead. Take a look at this for example.
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 wanna to simulate touch event in Windows / Mac OS X or Linux (OS is not critical).
Under Windows Vista and Windows 7, the Multi-Touch Vista drivers let you use 2 mice to simulate multi-touch gestures. It should degrade nicely to the "normal" touch experience. In my experience, it can be fairly tricky, but it works.
It really kind of depends on what you're working on and what the goal is. If you can separate the response from the action in your application, that will make it a lot easier to test something like this without going through a lot of hassle.
If you wind up needing a touch device, Wikipedia has a nice list of multi-touch devices.
A lot of time passed since this question, however, maybe someone will google for similar question and find that there is another option:
If you have android device, you can use your device as touch screen for windows.
Maybe there are other software to do this, but I used following one:
https://play.google.com/store/apps/details?id=com.tnksoft.winmultitouchfree
This program from some japanese guy coupled with desktop app does the trick.
You can get desktop app from his site http://www.tnksoft.com/ .
Unluckily it is japanese site, but it's not hard to find necessary program there(it has easily recognisible icon)>
Alternatively you can get link once you install android app.
I am a .NET programmer who needs to port one good Desktop OTP system already at work to be used into cell phones. As far I know J2ME is the correct answer to do it. I'll appreciate any good advice about IDE, first steps, books or any other information.
Well, Eclipse IDE have good J2ME support, or so I've heard.
For api, read the javadocs:
http://java.sun.com/javame/reference/apis.jsp
You'll have to figure out which device you want to target, and grab its emulator.
Then, proceed making a hello world app with the aid of tutorials.
I would give NetBeans a try as well. Eclipse and NetBeans are very similar, but the differences can be night and day depending on your personal preferences. NetBeans also has great J2ME project support, and it is plug and play for any emulator of a device you may need to target, though I recommend sticking to the default or SonyEricsson's. Motorola's was always buggy and never reflected the device at all, and Nokia's was always sloooow.
Also, there are a ton of devices out there. Before you jump head first into this you should define a scope of exactly which devices you will need to target. This will have a huge impact on scheduling as porting is no small task.
Finally, just get your hands on the actual devices you need to target. Emulator is a good way to start, but there are always so many nuances and problems that pop up once you throw the app on the device that it's best to have your target devices from day one.