You are here
Free Libre Open Source Software
This is a kernel module I cooked in a couple of days. The idea is to expose a v4l device that gets its data from user space.
I had 2 use cases in mind:
1) Educational purpose for myself (I'm really a kernel noob).
2) Streaming movies over skype, google talk, ... etc.
The idea could be good or completely rubbish but hey ? Learning can only be done with stupid ideas!
The code is highly unstable. It shouldn't oops the kernel but I'm not responsible. I've been developing and testing it inside qemu.
Clone it from the git repository via:
git clone email@example.com:vcamera/vcamera.git
Here are a few missing bits off the top of my head:
* I'm not following the kernel coding style yet ;-)
* I'm sure my locking, unlocking and concurrency handling is flawed.
* The code is a bit fragile.
* It'd be nice to implement mmap support for the character device. This should eliminate data copies.
* Perhaps expose the character device all the time and generate "fake" frames when streaming starts ? Problem now is one has to be very fast in feeding data to the module otherwise select() on the v4l device will timeout.
* Many more...
If someone finds this idea useful, please drop me a line.
Comments, use cases, ideas and tips are really welcomed!
If I see a lot of interest, I might try to push it to the kernel tree one day ;-)
Update: Seems vloopback already exists and renders my code useless. I might still do something with it as my idea seems a bit simpler but whatever.
The gitorious repository now contains a broken mms-manager, a non functional mms-ui (because I changed the DBus interface ;-)), a preliminary mms viewer and a broken network connection manager. How pretty is that ? ;-)
I've been redesigning the DBus interfaces and I think I reached something. The UI can be easily adapted after that.
However, I'll be on vacation until the end of February. I can't work on mms until I'm back.
I'll try to commit and push the code I have on my laptop but the stuff will still be broken.
This is just a quick status.
Good wishes for the newly married couple ;-)
As promised yesterday, I'll start cleaning up my code a bit preparing to post it here.
Here's mkmms. It's a minimalistic application that allows you to create an MMS and attach ONLY 1 file which can be jpg, png, gif or txt (I hadn't tested anything beyond jpg).
Note that it's alpha quality.
There's also a parser that will print some info about any MMS passed as an argument but it's commented out.
Use it like this:
./mkmms <to address> /home/mohammed/me.jpg m-send-req.mms subject
It needs QtCore and only that.
Don't ask about the license. It uses some bits from Qt extended, some from mmsdec and some are my own but you should be OK if you assume GPL for now.
I wrote it to make sure the MMS library works and to generate MMS messages to test.
Next, I need to clean up my sending code and post it.
Now a bit about MMS:
MMS is just a bunch of attachments cooked together using the WSP encapsulation protocol.
A typical MMS consists of a header and a body. The header contains the From, To, CC, BCC, Subject, ... parts.
The body contains the actual parts. A part can be a video, an image, some text or anything (Not exactly sure).
Now there's something called SMIL out there.
SMIL is some sort of XML that tells the "phone" how to render the MMS. MMS can contain a SMIL part and that's usually the first part of the body (I think the standard demands it being the first part) but it doesn't have to be there.
For now, I'll ignore something called SMIL at all.
Next: Sending MMS to the actual gateway.
I've spent the past few days trying to get MMS to work on the N900.
I started by trying to enable receiving so I can try to monitor DBUS and see what's going on. This failed and my operator (Elisa Finland) sent me an SMS stating that they can't send me the MMS configuration and I have to send an MMS first (According to Google translate's Finnish to English translation).
I then decided to try implementing sending.
I needed a custom MMS encoder so I can build my MMS. I also discovered that I know nothing about these things and started working on an MMS encoder/decoder.
I used a sample MMS, enjected my number and kept trying.
After long hours of working, I managed to hear my N95 vibrating and it was it :-D
This is just a proof of concept. Sending works. I need to figure out how to receive the wap push notification and how to bring up the GPRS connection in a clean way.
I'll post detailed instructions and the code I used when I get some sleep ;-)
Here's the HTTP headers sent:
User-Agent: NokiaN95_8GB/31.0.015; Series60/3.1 Profile/MIDP-2.0 Configuration/CLDC-1.1
Accept: */*, application/vnd.wap.mms-message, application/vnd.wap.sic
Accept-Charset: utf-8\r\nAccept-Language: en
Ah, and I didn't yet parse the reply I've received from elisa's server ;-)
Thanks to all the hard work by the fglrx packaging team, DRI, MESA, Xorg, Radeon,... etc people!
I've been using fglrx with my laptop since I've had it:
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400
And to the people behind the Debian packaging..
* xserver-xorg-video-radeon from testing.
* libdrm-intel1 and libdrm2 from unstable
* libgl1-mesa-dri and libgl1-mesa-glx from experimental
vader:~# apt-get --purge remove fglrx-driver fglrx-kernel-src fglrx-kernel-2.6.26-1-686 fglrx-sourceReading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
0 upgraded, 0 newly installed, 4 to remove and 17 not upgraded.
After this operation, 38.8MB disk space will be freed.
Do you want to continue [Y/n]?
I probably lost the ability to suspend and resume but I don't usually do it with that laptop.
Now let's hope my lapop at work will be adapted easily too :)
UPDATE: Seems you lose OpenGL 2.0 if you use the free driver. If you are doing OpenGL stuff like me then you are in trouble ;-|
Yup, thanks to Matan Ziv-Av who did a few improvements and fixes and uploaded him-arabic to maemo extras.
The good part is the addition of the Hebrew keymap (And a few other things).
The bad part is dropping the dependency on ttf-arabic.
I need to create a metapackage called "arabic" that will pull all the packages needed to support Arabic.
Well, I'm still using the ttf-arabic packagess I created for Chinook (Available from my FTP as I don't have a Diablo repository).
I won't create the arabic metapackage anytime ssoon as I'll be on vacation. Wish me luck ;-)
This post has a bit of my history and emotions. It can be skipped!
The summary is: Katoob has a new maintainer.
Yes, a long time.
Back in 2002, Gtk 2.x was just released. Efforts were spent porting, rewriting and redesigning parts of GNOME. The aim was GNOME 2.0 and later on 2.x
Previously, we had Gtk which did not support Arabic at all.
At that time, the only usable Arabic capable GUI editor was a closed source one, Axmedit. I was also trying to learn programming and write something useful. Katoob was born at that time. The aim ? provide the Arabic user with something usable and the secret agenda was me learning Gtk and get my hands dirty with C. Not having enough skills to contribute to something as large as GNOME.
It wasn't called Katoob (Which means something like an exaggerated writer in arabic). Me and Alaa wanted to call it gDhad (G is for GNU, Gtk, GPL, ... and Dhad is the letter. Arabic is known as the language of "dhad") but a miscommunication lead to that name.
The problem is that it was already used by a few of my friends. A lot of testing has been done in the beginning. I still remember feeding it various media files as well as random garbage to see what will happen.
Years later, the whole thing grew into a pile of spaghetti code. It was the time for me to start learning C++. What else can I use to learn it ?
Then 0.5 was born. A bit cleaner, C++, Gtkmm and moving it to my own place. It even survived my migration from CVS to SVN last year.
It also started to be used by more people.
As I become busier with work and as my interests have started to change, I found myself incapable of maintaining it. It's actually a motivation problem more than anything else. I'm not involved into Arabization issues (I was never involved but people claimed I was ;-)) and I wasn't getting enough testing.
I don't use it a lot anymore. Everything supports Arabic now. I don't think we need that project anymore.
I can also use Emacs to read and write Arabic
OK. This is the beauty of FOSS. The project has been dead upstream for a while now. It survived until it was removed from lenny.
Now me and 2 other users decided to adapt it. port it or rewrite it in gtk2.
We are having a discussion about the whole situation.
To anyone still using multi-gnome-terminal: Please share with us the features you were actually using. These are the ones more likely to be implemented and no new features will probably be added, maybe help us coding and/or testing or participate in the discussions.
I'm getting a lot of questions on how to enable Hebrew under maemo. I know that the fonts have been packaged already and I guess there's also an input method. It's as easy as writing an XML file for my not so broken Hildon Arabic input method.
I just don't understand why can't they be made available publicly or made known ?
I can neither host nor support them, nothing personal. It's just that I don't know Hebrew and I can't support a language I don't know!
Please, oh pretty please with sugar on top, can someone give me a URL or at least share the information so I can at least copy and paste it as a reply to the emails I'm getting ?