Liqbase, open source virgin
 

As many of you know, I have written liqbase which at its core is a small library for drawing quickly onto the YUV overlay.

http://www.internettablettalk.com/fo...ad.php?t=21259

This allows very rapid screen updates and the control of the screen resolution and cpufrequency to get even more speed.
At this point I have not released the sources and have just given a preview video and playtest binary.

I've been working on the graffiti/sketching aspect and have built myself a library, but things are slowing down a bit for me. I don't have enough time to advance things as fast as I would like (and I would *really* like to spend more time doing this)

What do people think?
Is it cool enough to help show off our nokias?
Could it be used for other things?
What would you like to see rendered this way?

I've not written anything like this before (that I would consider releasing) and its very different to the sorts of projects I see around and personally think liqbase makes my nokia fly.
However, I am but one man and know the time has come to seek help.

I come from a closed source shop but have spent a great deal of time reading about open source (long time slashdot user..). I've flip flopped on this for a while now and those who are in #maemo will know this (:p rm_you).

I'm extremely nervous about releasing anything but know there are a lot of you who have knowledge I don't and can help to grow this into an amazing set of programs.

Am I alone in being nervous?
I'm interested to know what experiences people have had when releasing code and any welcome any advice.

This decision was made in the car this morning so nothing is uploaded yet but when I get back tonight providing I hear no horror stories I will try to park it in the garage tonight.

Re: Liqbase, open source virgin
 

Why do you feel nervous about releasing your code ?

I do think that a project like yours can get a good boost by allowing other experienced people in.

Re: Liqbase, open source virgin
 

No point being nervous here. You provide something useful and there's nothing that could go wrong imo. The only change is that you'll probably end up working in a team of some sort instead of locked down in the basement. ;-)

Re: Liqbase, open source virgin
 

Tried it just yesterday and very impressed. Release the source and let others help you develop it further and I have no doubt it will be up there with the other "killer" apps. You retain the kudos for creating it the first place and that can only increase by going the open-source route.

Re: Liqbase, open source virgin
 

Stick the code in a Garage project (as a library & demo application(s) - so people can use the library directly and also play with the demo apps), I am sure people will both use it and contribute towards it.

Go lcuk! :)

Re: Liqbase, open source virgin
 

I'm betting the library-side of things will really interest the INdT guys. Probably worth pow-wowing with them a bit, as they definitely have the skills to push something like this really far.

Re: Liqbase, open source virgin
 

I understand you don't want to make the actual application open source but I think many will benefit with just the library (and a demo :)

Re: Liqbase, open source virgin
 

What do people think?

It's a sound idea if you don't have the time to invest thoroughly into the project (or you're simply losing interest or creative direction!) At the very least - a documented closed-source library, a simple open-source app to utilise the lib, and some method of contacting you to add extensions to it would be beneficial if you're worried about source release.


Is it cool enough to help show off our nokias?

I've not seen scrolling done as smoothly as you've implemented - from a pure eyecandy perspective - it's definitely worth showing off :) I was also surprised with how useful the sketch application looked when you combine all the notes together! I think it's cool :)


Could it be used for other things?

Not sure what your library does tbh - what does it accelerate or draw to the screen? I see smooth scrolling text, a simple GUI, and a starfield - is it a fast pixel buffer? Could you write to it like a pixel buffer? Is it faster than SDL? If so it'd be useful for everything, emulators at a start, speedy Deluxe Paint type applications, Power Goo type apps, the start of a software 3D library, etc, etc

What would you like to see rendered this way?

The above :) - can you show off scrolling bitmaps, how about a smooth 2D bitmap transform on a set of CD covers (ala Apple Cover Flow.)

Re: Liqbase, open source virgin
 

Yabbas,

Its just a set of functions using the faster YUV display format (full grey resolution, lower color information: jpeg basically).
It has additional bonus of being able to run at any arbitary fullscreen resolution (within reason)

I decided this morning that I need to get the code out there and see what moulding is required to advance it further.

Its not feature filled and will likely have some massive omissions and clangers, but it does what it says on the tin and liqbase modules all show it in action.

It speaks for itself as a demo.

I could continue adding more and more modules to it now I have the basic code in place (as I have been doing) but don't have time to perfect each area and this is stuff which others may be able to find a better use for.

As for emulation type stuff, as long as the assets can be loaded as YUV I don't see why it couldn't be used and it certainly does give a visual boost at higher resolutions.

If you have the binary liqbase, go into options and there is an area called Blit Image Test, this has a kinetic scroller built up from actual fullcolor bitmaps.

Its lacking image loading code at the moment because i have been producing my assets directly from sketches or rectangles, but should be simple to include when required.

Re: Liqbase, open source virgin
 

The wheels are turning.
I have added headers and cleansed the code of much cruft (though theres still lots to pick at)
I have tar.gz'ed the code up and submitted a garage application.
No turning back now I suppose.

description to garage:

technology demo featuring finger friendly menus, variable resolution kinetic scrolling fullscreen document viewer, pressure sensitivity sketching with a graffiti wall showing all drawings, cpu throttling adjustments and a fullscreen starfield screensaver.

Re: Liqbase, open source virgin
 

Good show :D can't wait to see what comes from this!

Hi Lcuk,

The best way to predict the future is to avoid it.
But what is the fun in that? you already have the kudos and you really have nothing to lose.

Re: Liqbase, open source virgin
 

Virgin, eh? I used to be one of those. But then I one day I made a release and voila, a virgin I was no more. If I have one piece of advice, it is this: just do it. Of course in this day and age, you'll want to protect yourself. LGPL perhaps?

}:^)~
YARR!

*shhhh*

Re: Liqbase, open source virgin
 

Capt'n, I have decided to release under the GPL and have de-crufted the code base.
I have created the project (https://garage.maemo.org/projects/liqbase/) and am trying to get everything configured at this end for SVN updating.
Between my lack of knowledge about SVN and being confined within the 810 (I do all compiling direct on the device) its proving a little tricky.

It should all be up and running soon enough though and then I can get back to actually developing stuff.

Re: Liqbase, open source virgin
 

Good on you, bud!

Compiling directly on the tablet? That's mighty ambitious of you! Now I have *another* potential use for my tablet. Nothing like being able to code on the subway. The thought is mind warping.

I also have a new open source project planned, so keep us all posted on your foray into the world of public development, as I'm sure it'll be inspiring to more than just a few. I, personally, will be following your project with much interest.

A question. Disclaimer: I have extremely little assembly experience and none for ARM architecture, so forgive the imminent ignorance.

I assume that you're using the DSP in the OMAP to spit out pre-saved YUV graphics to the main display which allows for very fast full-screen updates, as it appealing the the DSPs specialization.

Aren't there DSP routines to convert RGB input to YUV readily? If so, couldn't they be used to convert RGB to the equivalent YUV colourspace and potentially speed up full-screen viewing for 'regular' RGB apps? Is this what libqbase already does?

I warned you that ignorance was coming! Anyway, if this is so, it would be GREAT if you could implement a wrapper, using libqbase, for a generic graphic library like SDL as it would INSTANTLY improve the performance of many full-screen applications.

Feel free to answer none of my questions! :D

}:^)~
YARR!

Zip Zap Cap

Re: Liqbase, open source virgin
 

No. Talk to raster on #canola if you want to know the specifics of why this doesn't work.

Re: Liqbase, open source virgin
 

Capt,

compiling on the tablet isn't that bad for this project. Each module is built in a couple of seconds and linkage is similar, its well within my annoyance threshhold at the moment. (if anything, this method is faster than the old way of using vmware scratchbox).

Being able to fixup bugs and do non trivial work on the go is amazing - i created the graffiti wall module whilst sat in the developer room at linuxtag earlier this year :)

There are a number of limitations which would prevent its use with other larger projects (lack of autotools is a major one) but it works for me.

I do not use the DSP for anything at this moment in time (and infact when the DSP is running the whole device runs slower..).
All code is aimed towards the cpu itself.

The amount of processing power required to do RGB->yuv conversion on the fly would make converting SDL a none trivial operation and I doubt would yeald acceptable performance benefits at this time (Lardmans DSP investiagations may surprise us!).

In the future however I am hopeful we can make use of the rest of the specialist hardware within the OMAP2420 chip package, this includes a hardware RGB->YUV conversion and of course the powervr 3d hardware but this appears to be a non-starter at the moment.

Another possibility is to use the same YUV graphics mode under X11 itself and actually run maemo very quickly in greyscale (sidestepping conversion altogether) - a major compromise, but something "technically" possible which linux/x11/maybe SDL supports (8bit greyscale framebuffers exist).

Thank you for your interest in the project and I am also hopeful that we can build an extensive collection of exciting software toys and projects to show off our nokias.

Re: Liqbase, open source virgin
 

Patch the kernel for a different op_mode. Although saying that, I wouldn't expect you to expect endusers to do that :)

Re: Liqbase, open source virgin
 

@GeneralAntilles

After looking a the conversion function, I can understand why it's not feasible to expect speed (or efficiency) gains calculating an RGB to YUV conversion in run-time:

Y = 0.299R + 0.587G + 0.114B
U = -0.147R - 0.289G + 0.436B
V = 0.615R - 0.515G - 0.100B

Although the formulae are linear and simple, there are two problems (as far as I can see). First, pixel setting is a PRIMITIVE operation and any calculation you add (even a simple one) tends to have a large impact due to the huge amount of times the operation is called. The next is the dreaded floating point, the Achilles heel of the N8x0, and this formula is ripe with floating MULs. Of course, the increased calculation will translate to an increased battery drain, which is not really good for anybody (except the sadists -- bless their little hearts).



@lcuk
Awesome. This has given me a ton of information and a much clearer idea of what's going on.

I'm betting that the simplest and quickest way to do run-time RGB to YUV conversion would be to use a pre-calculated lookup lookup table of conversions rather than run time calculation. Even storing a 16bit RGB to 16bit(?) YUV tabel would only require ~260K of system memory:

(2ByteRBG + 2ByteYUV) * 65536colours == 262144Bytes ~= 262K

[edit]
There is an error in this calculation. The correct size of the lookup should be:
2ByteYUV * 65536colours == 131072Bytes ~= 128K
It is not necessary to store the RGB index as a part of the table :D
[/edit]

SIDE NOTE: In this instance the N810s 16bit colour capabilities comes in really handy as it keeps the lookup small. 24bit would be quite a bit larger or require an additional bit shift to map the RGB to the YUV. Not terrible, but not ideal either.

Now when SDL sets a pixel, it does it the easiest way possible, by implementing a frame-buffer (block of memory) that you write directy to at a pre-calculated offset (depending on the depth and resolution).

This is where the wonderful compile-time construct the C/C++ macro definition comes in. If all of the pixel setting routines in an SDL app could be found, then they could be easily wrapped with a macro that compares the dynamic RGB with its YUV equivalent on the table *and* writes it to the frame buffer at the desired offset without requiring a costly function call.

To accomplish this, there will have to be a port and inspection of the code, but it *should* be straight forward enough to be done in an afternoon by a gifted porter. I'm guessing that the majority of applications would have their pixel setting done in only in a select few places anyway.

Now, using libQBase as a wrapper to an N810 specific version of the YUV SDL library (RGB/YUV macro lookup), we get minimally ported SDL apps that are spit out not to the X frame buffer, but more directly to the OMAP hardware. I'm guessing that there will be large speed increases for relatively little work!

I know I'm not telling you anything you don't know, just engaging in a little group problem solving. I'm confident that we can bust this nut wide open, figure out a way to squeeze new speed out of existing apps, and use libQBase to enable a new breed of N810 app.


Coding and *compiling* on the go is clearly amazing. I get excited just thinking about it!

How long would you say that battery lasts whilst coding up a few text files? What about reading text files (like documentation)?


I'm hopeful and confident as well. Keep moving forward and I'll see you there.


Cheers

}:^)~
YARR!
Capt'n Corrupt

Re: Liqbase, open source virgin
 

I would like to add:

Setting anything other than full pixels in the method above would introduce another level of complexity, not solved by the methods above.

}:^)~
YARR!

Dr. Corrupt

Re: Liqbase, open source virgin
 

Captn,

I find the battery on my 810 to be quite resiliant, I dont play music on it or use it for wifi during the daytime and I keep my screen off maximum brightness and I am able to pull out and use my nokia for coding/compiling/sketching/looking/playing/reading whenever I need it.

During linuxtag I was sketching and doodling the whole trip and my nokia outlasted others, we all went out to the pub and my nokia which hadnt been charged all day was the only one still working and able to play numpty (at full "performance" speed might I add)..

Now, sdl and automatic translations - your pondering is slightly off.
YUV data is actually 12bit, but it is not stored in a single short integer 16bit memory block.
The YUV data available by the Xv library is planar based with a whole 8bit greyscale chunky bitplane (w*h bytes) followed by 2 1/2 resolution chunky planes for chroma channels each of ((w/2)*(h/2)).
This means that to specify a color you need the full 24bit YUV value.
The colors are fully detailed but the number of pixels to draw on aren't.
So to get maximum coverage your rgb16->yuv table would have to store the whole 65k * 3 192kb
To use a table for the inverse would require mapping the whole 16.7million possible YUV colors for a pixel to a 16bit short per pixel...

Coupled with the fact most atomic SDL operations do not require pixel based lookups or assignments makes me think this table looks a little infeasible but its good to discuss and talk through suggestions.

Looking at performing the conversion via a function would be better and I believe there are already quite rapid integer only examples available.

Now, looking specifically at SDL, most games etc will load their assets as images and just be dealing with blitting them onto the screen at specified locations based on the game control code.
Loading an SDL image will create an SDL bitmap in a compatible format for the display mode you have created.
This means that any ImageFileRGB->ImageYUV would be done once at loading as long as the blit routines could work with YUV surface and YUV image..

I think the SDL underlying structure supports YUV or was intended to originally, I seem to recall seeing branches for YUV.
If it does, I personally see no reason why a new backend interface couldn't be hacked to make SDL talk to X11+xv...

This is not been a priority for me, I have learnt more about coding my way and did not understand enough about x11 or sdl when I started all this, it would certainly be interesting if it could be done.

Re: Liqbase, open source virgin
 

Thanks for the enlightenment. It's always a bit of a pisser to find that a single wrong assumption is enough to capsize an idea.

But I'm resilient (or stubborn -- depends on your perspective). :)

Putting SDL aside for the moment. I'm interested in effectively utilizing the YUV (Xv?) on the tablets.

This is mildly mind-asploding. Are you saying that in order to set a YUV 'pixel' one has to write to three separate memory blocks of varying size (or equivalently three offsets of the same block)? Or is this automatically done using XVideo extension?

After looking over the Xv manpage I found the functions XvGetStill and XvGetVideo that accept drawable data, clip the data, and spit it out the hardware. I'm assuming that they accept the 'drawable' in YUV format. This is what I assume libQbase is doing.

So does the developer concern shclimself (or shclurself -- to be genderless and politically correct) with the chunky planes? How large are each individual Y, U, and V value?

Feel free to answer none of these questions. Seriously, I won't take offense at all. I'm intensely curious and it can get annoying.

Actually, 16bit to 24bit isn't that bad *if* it is indeed a mathematical function (one to one). The total size of the lookup would be 65Kcolours * 3Bytes (24bits) == 196K lookup.

Mapping the YUV to the the "2.5 resolution" chunky plane is the confusing bit. Are you suggesting that because of the 2.5 resolution, somehow more than one value would have to be stored for each mapped colour? Or is it simply a problem of splitting the result among the different planes?

The inverse operation, though, is quite terrible (as you rightly suggested). The lookup problem can be mitigated somewhat by bit shifting each Y, U and V components to achieve a smaller approximation (and index) of the original colour and then mapping that YUV result to its RGB equivalent. The many shifts for each pixel would likely have steep computational consequences, and would have to be tested to determine what the consequences are. This is all moot as thankfully YUV to RGB isn't the primary concern.


So true.

This would be useful for a great many of cases, but something would have to be done for applications that quickly want to write individual pixels. I remember some 'demos' of ray tracers implemented in SDL and the sort that would certainly require pixel level control.


Nor should it be! I'm impressed by your work and understanding. I'd love to contribute, if only with ideas.

I fully endorse just jumping in and trying something out without collecting all of the facts. Unique solutions tend to be developed that way and a deeper understanding of what you're working with can be gained.


That's amazing, and exactly what I want to hear. Even most lappies running basic applications can't boast life like this. As long as I don't have to constantly worry whether my tablet is going to die on me, I'm well happy.

How do you type on the N810? Using the built in keypad? How well does this work? I suspect using a wireless bluetooth keyboard would drain the battery (though the keyboard would likely be sending information to the bluetooth receiver more than the other way around, so I could be wrong).



}:^)~
YARR!

Cappie

Re: Liqbase, open source virgin
 

theres quite a lot here and I don't know how to insert quotes and stuff properly, so if the formatting is off bear with me.






Even a wrong idea expressed in the right way can yeald positive results.




Yes, 3 memory locations, however when processing I do all operations on a single plane then move onto the next.
There are write operations which work in greyscale only, and variations added later which simply call the same macro with alternative parameters and dimensions for the remaining color planes.
It works well enough for now and allows me to use int32 writes where needed.

xv simply gives me a blank canvas to write on.




I simply call XvShmPutImage to push the already allocated blank canvas to the LCD. This call will raise an event in the X11 event chain for my window to say when transfer has completed. If I try writing to the canvas data during this time then extreme tearing occurs.
I have attemped in the past to call the same function from within SDL during its refresh process (sdl uses the same underlying shared memory setup, just a different format).

There is a discussion on here or the net in general about tearing where I attempted this but did not get expected benefits - though I missed something out there, at the time I didnt realise there could be intermediate events and needed a function to wait until the window got the event to let sdl carry on drawing, hmmm perhaps if i...





There are 3 planes, and I want an 800*480 display
Plane 1, 800 pixels wide, by 480 pixels high, 8 bit Greyscale.
Plane 2, 400 pixels wide, by 240 pixels high, 8 bit Chroma *.
Plane 3, 400 pixels wide, by 240 pixels high, 8 bit Luma *.

*if im wrong about names you should know what they are expected to be.



I'll help as much as I can because explaining things now will help in the future.


I still don't quite understand the mathematical function you are on about, if you are suggesting using a function to calc offset then do the lookup to then write it to the destination then that would be orders of magnitude longer than the quickest assembler operations on register variables - just use an optimised function to convert as required.
you can do the matrix transformation in strips anyway and grabbing data 4 pixels at a time and modifying the target pixels in bulk would help.




I will restate what I said:

The YUV data available by the Xv library is planar based with a whole 8bit greyscale chunky bitplane (w*h bytes) followed by 2 half resolution chunky planes for chroma channels each of ((w/2)*(h/2)).

2 in quantity, half resolution each.






Use the all cpu function to do translation between yuv->rgb.
It has to be as much of a concern as rgb->yuv. they are yin and yang functions and to make one good you will have the skills to make the other one well.
If somebody came to doing the functions creating the inverse at the same time would be beneficial.


Programs that require RGB attributes and who dont check that their bitmap is actually rgb dont care about it not running on yuv, and they simply wont run no matter what we try. its not the end of the world.



:)




So am I. the only niggle for me is that I use adhoc wireless - it *does* drain the battery faster when connected, but thats only around the house and im near a wallwart, when out and on wifi its never been a problem.


When I'm tinkering i use the keyboard built in, but its not ideal for typing, so when i think ill need it I take my apple bluetooth keyboard with me. its not foldable, but its about the size of a book and can be put in the bag easily.

Never ever noticed the battery drain with bluetooth.


Gary

Re: Liqbase, open source virgin
 

Thanks for the thoughtful reply. I'll keep this much shorter than previous posts as it *is* getting a bit long. :)

I think I understand how liqbase works a little better now. By writing the YUV data plane by plane you certainly can achieve very, very quick speeds, fewer memory operations and the benefit of Xv acceleration. This is especially true if you're saving data in a format friendly to YUV plane separation. Quite clever!

What about writing to a separate buffer/canvas? You can likely update the 2nd buffer while the first one is being processed by the hardware, and when it's done, you can quickly feed it the next one. This should eliminate the tearing effect and not require you to wait for the output before you begin drawing the next frame.


I should have articulated myself more clearly. The 'mathematical function' was in reference to a one-to-one mapping between each RGB value and YUV values, all represented in an indexable table. By 'offset', I meant 'table offset' or 'index.'

The idea is to reduce calculations for RGB colour conversion. Rather than having to do 3 floating point multiplies and 3 adds for 3 separate components of YUV for a single converted pixel (27 ops not including assignments, shifts, etc), you would only have to do only 1 memory lookup. The savings in calculation are huge even for the most optimized of functions, and the memory penalty is quite tame (196K table). Additional computation savings can be had if the conversion lookup is done via a macro rather than a function call.

Mapping the resultant Y value will be easy: the Y resolution is the same as the canvas or output resolution. Mapping the resultant U and V values reliably to a half-resolution is another story, but probably could be done a variety of ways.

Of course if there are hardware accelerated features that could perform the conversion, it would obviously be the ideal solution. :)


In all of this conversion talk, I didn't stop to consider if writing to the screen in native RGB was quicker than converting RGB to YUV with a lookup to write to the screen via Xv.... Go figure... If lookup conversion results in quicker speeds (Xv acceleration), it's something to look into, if not, it's been an educational ride!

Sadly without a tablet I'll not be able to find the answer to this question. Hopefully the screen writing speed bottlenecks disappear with more sane engineering on future versions of the hardware.


}:^)~
YARR!

Corruptieon

Re: Liqbase, open source virgin
 

Captn,
I hadn't considered a fully double buffered approach like you suggest, I had it in my head that xv will give me a screen and I draw to it.
It seems obvious in retrospect and could yeald additional performance benefits (especially for the lower cpu modes).
When I next dip my head into the engine I'll take a look around and see if theres anything I can do.
Thanks for the tip, it very likely may be useful.


Why haven't you got a tablet?

Re: Liqbase, open source virgin
 

A boring story, really.

I decided to hold off on getting the N810 in lieu of the impending N810 WiMax edition. I'm re-thinking that decision, though. I'm not sure when a compatible WiMAX deployment will happen here in Ontario, Canada, and based on the history of the big providers, the service will likely cost an arm and a leg! If the N810WME is released soon and there's confirmation that it'll work well with the WiMAX services in my area, then I'm all for it. If not, then I'll get the N810 instead.

Procrastination or prudence?

Anyway, I know this device will be a third (or fourth -- heh heh) leg for me in that I'll always carry it around with me and get plenty of use from it. $400 seems a bargain considering the multitude of things it can do.

I'll give it another month, and then think it through again. I'm both patient and frugal (a euphemism to make me feel better about being me) so I don't mind waiting for a good purchase. In the meantime I can do without. However, not a day goes by where I find a situation that having this wonderful tool would make life easier.

When, and more importantly, why did you get yours?



}:^)~
YARR!

El Capitarino

Re: Liqbase, open source virgin
 

Captn

The best way I can answer that is by giving you a link to the notes I made before Linuxtag.

they explain basically everything, I began to present a pared down version at linuxtag before bottling it ;)

http://liquid.googlepages.com/linuxtag_notes

Re: Liqbase, open source virgin
 

Fantastic read! I think I perfectly mirror your feelings toward the N810, but your story is articulated in such an epic way!

For a project that I'm currently working on (proprietary non-tablet related), I too had to write a resolution independent glyph renderer! A very strange coincidence, especially since I too didn't know what I was getting myself into originally!

Good show!

If you're writing a GUI, I would *love* to shoot some ideas past you. I believe that the fanciness of compositing WMs (minus the 3D) can be implemented in software with very little code. I would love to see liqbase usher in a new alternative to the dried up desktop style guis that we've seen time and again.

Your note taker is a BIG step in the right direction. It looks AWESOME and is something I would use constantly! Blast, if only I had an N810 to test it out!


}:^)~
YARR!

St. Corrupt

Re: Liqbase, open source virgin
 

There are fixed point RGB->YUV approximations which should yield good results:
http://en.wikipedia.org/wiki/YUV#Num...approximations

Wonder whther CLUTs are faster or slower than a few mults and bit shifts.

Re: Liqbase, open source virgin
 

Quite an interesting approach to RGB to YUV conversion. I like it!

This is certainly a useful technique that will save on a buckload of (expensive?) floating point operations in lieu of simpler integer and shift operations for each colour channel.

I would *guess* that using a CLUT (colour look up table -- for the uninitiated) would be faster than muls, adds, and shifts (~21 ops per colour vs 1 op for lookup). Of course, this is all contingent on the length of time it takes to fetch something in RAM relative to on-chip speed for general (or specialized) calculation. The easiest way to find out, would probably be to code a converter in assembly and speed test it against a CLUT.

I can't wait to start messing about with the OMAP hardware... :D


}:^)~
YARR!

Copt'n Carrupt

Re: Liqbase, open source virgin
 

anything that improves the video performance of the n800 & n810 has got to be worth investigating! will this also help the 770 too?

Re: Liqbase, open source virgin
 

Try it and see.

I don't know if it will work, it might use libraries not available or more fundamentally not support it at all.
I haven't got a 770 here and don't think anyone has attempted it before.

The most recent source is in the liqbase garage svn.
I thought I would get a new package for the 8x0 out tonight (but gonna have to wait till tomorrow now, im way too tired).


Please post further feedback in this thread, I'd be very interested to hear how it goes:
http://www.internettablettalk.com/fo...ad.php?t=23854