Re: MPEG in GGI?
On Mon, Apr 17, 2000 at 11:39:35AM -0400, Stefan Seefeld wrote: On a different note: the Berlin project will present itself on LinuxTag in Stuttgart this year, both, with a booth as well as in a talk. Does anyone from GGI intend to show up in Stuttgart ? May be we could meet and discuss various aspects of the above... I'll be there. I would be pleased to meet someone from the list there at stuttgart. Regards, Stefan thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
Re: embedded qt
On Tue, Mar 21, 2000 at 11:17:50PM +, Justin Cormack wrote: http://www.trolltech.com/announce/embeddedqt.html Trolltech are producing a version of Qt that doesnt require X, running directly on the Linux framebuffer. Anyone know anything about it? It claims to offer acceleration. they will hit the framebuffer directly without the support from a additional library. BTW: the license issue is currently dicussed by the troll. Justin thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
Re: ggi2dDrawArc, ggi2dFillArc
On Fri, Mar 10, 2000 at 03:18:15PM +0100, Christoph Egger wrote: On Wed, 8 Mar 2000 [EMAIL PROTECTED] wrote: Hi ! At least, I know I will need _exactly_ these drawing functions to have _all_ the rendering capabilities required for the OpenAmulet GUI library. Could you give an API wishlist ? I might attack reimplementing LibGGI2D in a way that makes it more consistent with the other extensions and allowing to HW-Accelerate much of it. I wish to have: int ggiStrechCrossBlit(ggi_visual *src, int sx, int sy, int sw, int sh, ggi_visual *dst, int dx, int dy, int dw, int dh); It should does the same as ggiCrossBlit, except it also performs streching. i haven't followed the discussion, but ... Streching with or without CrossBlit comes down to the same accel on some gfx-cards. it would save one accel if we would have such a combined command. But I think, this should go into libggi and not libggi2d... Comments? Christoph Egger E-Mail: [EMAIL PROTECTED] thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
Re: targets and ?sources?
On Sat, Feb 05, 2000 at 04:46:58PM -0500, teunis wrote: On 5 Feb 2000, Marcus Sundberg wrote: [EMAIL PROTECTED] writes: The second library should be a simple glue-layer between the first library an LibGGI. The reason to make two libraries that a generic image loader/writer that is _not_ tied to any graphics/window system is badly needed, and the first library will be just that. On image grabbing: This is good, very good. Would work for stills, scanning, digital cameras, On -video- capture (ie stream of messages): No. Absolutely not. Frame grabbing has -terrible- problems with two things: 1. It goes very fast. Hard to capture 30fps at 640x480 straight into a raw buffer... ggitv gets 25fps in 640x480 by video-card-X-gfx-card (NO overlay). 2. Drivers aren't very stable... *sigh* [for bttv] which driver are you using (driver-version, hardware) ?? Anyways, you'd have to do a different interface for -video- capture than for image capture anyways. Mostly due to latency problems. I want that personally (mind you, I don't use GGI to -play- videos either other than to supply a frame to write to ... it doesn't fit the purpose) G'day, eh? :) - Teunis thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
[root@wesley.informatik.uni-freiburg.de: Cron ggi@wesley ~/bin/update]
once a month i get this message from one of servers. is here some who is responible for this message ?? - Forwarded message from Cron Daemon [EMAIL PROTECTED] - Date: Thu, 6 Jan 2000 13:15:01 +0100 From: [EMAIL PROTECTED] (Cron Daemon) To: [EMAIL PROTECTED] Subject: Cron ggi@wesley ~/bin/update X-Cron-Env: SHELL=/bin/sh X-Cron-Env: HOME=/home/ggi X-Cron-Env: PATH=/usr/local/bin:/usr/bin:/bin X-Cron-Env: LOGNAME=ggi rm: ggi-devel-*: No such file or directory - End forwarded message - thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
Re: yuyv
On Thu, Nov 25, 1999 at 09:41:06PM +0100, Andreas Beck wrote: Hi ! i thought about the yuyv-topic again. a packed yuv422 buffer can be transformed into a planar yuv422 buffer. this way you get 3 buffers. one for Y (size is T), one for U (size T/2) and one for V (T/2). can't this buffer be accessed like those vga 4-bit plane-buffers ?? No. VGA-4-plane was handled in a somehat weird way, right. We used a planar read configuration and a color-switched write configuration. However the assumption, that each single pixel can be controlled individually still held. The YUVU setup is different. It basically doesn't really fit the GGI picture of a "normal" graphics mode. For the operations covered by LibGGI I would suggest to handle it like a mode that has the "Y" resolution. Thus if you set a pixel, the neighbouring pixel will get the same color values u/v as well. This is IMHO the only consistent way out. It isn't too bad, as the reason for subsampling u/v is, that the eye has not as much resolution for color than for greyscale. It has some strange implications for read/modify/write stuff, though. Well - on colormapped modes we have similar problems. For the DirectBuffer we might want to define a new possible entry for the bitmeaning field that would mean "u on even pixel numbers v on odd ones" or similar. The other alternative would be to allow some new kind of directbuffer that can hold multiple entries, one for each "plane" (the planes happen to be stored in an interleaved fashion in our case). This would more generically allow for such subsampled formats. i vote for this one. this is the only reasonable way that covers all my needs in handling the buffer, but i doesn't cover the packed layout i can get from the tv-card nor it does cover the layout your gfx-card is using. (YUV422 is nost often packed) i can live with the planar ones. There is also a double-subsampled format, where a pixel-quad (2x2) shares u,v but has 4 y values. My hardware doesn't have that - do you know, how it is stored ? v4l2-page: http://millennium.diads.com/bdirks/v4l2fmt.htm there are 4:2:2 - packed - YUYV 4:1:1 - packed - YYYUYYYU YYYVYYYV 4:2:0 - planar ! - your mentioned 2x2 matrix (don't know it's layout in memory) 4:1:0 - planar ! i really this a ggi-support for this topic and need your opinions and suggestions to set something up that take care of colorspaces != RGB. Yes. I have an application for that as well. can you talk about it ?? some mpeg-stuff ? Well, we have hardware devices that export those formats - TV-out cards. So we somehow have to cover them. And I'd really like to be able to run LibGGI apps on _anything_, so ... CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] = thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
yuyv
second attempt. i thought about the yuyv-topic again. a packed yuv422 buffer can be transformed into a planar yuv422 buffer. this way you get 3 buffers. one for Y (size is T), one for U (size T/2) and one for V (T/2). can't this buffer be accessed like those vga 4-bit plane-buffers ?? i really this a ggi-support for this topic and need your opinions and suggestions to set something up that take care of colorspaces != RGB. andy, marcus: your last responses went into diffrent directions. can we come to a comment point of view ?? thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
test
can you hear me ?? thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
Re: how to display 30 frames/second?
On Thu, Oct 21, 1999 at 11:28:12AM +0200, [EMAIL PROTECTED] wrote: Hi ! i have a yuyv-rgb routine that gives me 13 fps at 756x568. I'd like to have a look. I've written a bunch of those as well, and it seems hard to get them quick and correct at the same time. My quickest one uses a u,v lookup table and then does something like r=g=b=y; r,g,b+=table[u][v]; clamp(rgb);. the attached code is taken from xawdecode (http://freetv.notrix.de/ - linux) it consists of init_decode that initialisises the colortable and decode_halfframe that convertes the provided yuyv buffer into a rgb-buffer including downscaling (x and y). putline??.s provides the neccesary assembler-routines (x86-mmx) to convert and scale the line in x-direction. putline15.s is for 15bpp, putline16.s is for 16bpp. to compile putline.s you need NASM. CU, ANdy -- Andreas Beck | Email : [EMAIL PROTECTED] thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(- yuyv.tgz
Re: phys. address of a framebuffer
On Sun, Oct 03, 1999 at 06:59:20PM +0200, Marcus Sundberg wrote: Andreas Beck wrote: Hi ! is there a way to gain the phys. address of a framebuffer in ggi ?? No, as this was never needed up to now. However I see your point, and it might be a good idea to add it. I think a function for this will fit togehther with the API for allocating video memory, right? yep. but i think that a field in the directbuffer-struct would be ok, too. No need for such complicated stuff. KGIcon drivers as well as native fbdev drivers gives the physical address as well as the length of the framebuffer in fix-smem_start and fix-smem_len. The DGA target also has the needed information available. yes. i know that. but i don't know how to set up the neccessary API //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED] thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
