[Xpert]Geode kdrive
Hi Alex! I followed this thread on the Xpert mailing list and I also have Geode based device that I would like to get up and running with X. My problem is that in order to do that I need to be able to do 1024x768 @ 72Hz with 90 degrees of rotation. Could the X 4 driver you have do that?? And if so could send me the driver as well or give me a URL from where I could access it?? Thanks a whole lot in advance, Patrick After going back and forth with National, it turns out that the NDA does not apply to their source code, which is dual-licensed BSD/GPL. Since they show no interest in distributing it, I guess its up to me, and I'll get it up on a website shortly. If you want it now, email me and I'll shoot the code over to you. Alex Pavloff Software Engineer Eason Technology ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Geode KDrive
Is the National NDA unrestrictive enough, so that you will be able to make use of these functions without infringing it ? Just a question, I am myself wondering if it is worth to sign it (that's the only restriction in my project , and stops it from complete publication)... Best regards, Rolland Alex Pavloff wrote: Hello folks. I have a National Semiconductor's Geode XFree86 4 drivers. These drivers can be run in two ways 1) sitting on top of National's Linux Framebuffer drivers and calling acceleration functions (ioctls) provided by the framebuffer drivers. 2) doing all the work themselves. I want to make a TinyX server that uses these accelerated functions. Now, what's my best option: Option A) Hack the kdrive/XFbdev source to call accelerated functions where possible. The rendering functions provided by the Geode driver are: Gal_set_solid_pattern Gal_set_mono_pattern Gal_set_raster_operation Gal_pattern_fill Gal_set_solid_source(unsigned long color Gal_screen_to_screen_blt Gal_screen_to_screen_xblt Gal_bresenham_line There are many other functions available, but since this is going in an embedded device, I'm not too worried about setup issues and much more concerned about how fast the thing is going to draw. Option B) Attempt to figure out what Keith Packard was doing with the other drivers in the kdrive directory, and modify the geode source code to match that. Suggestions/Comments? Alex Pavloff Software Engineer Eason Technology ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Geode KDrive
Hello folks. I have a National Semiconductor's Geode XFree86 4 drivers. These drivers can be run in two ways 1) sitting on top of National's Linux Framebuffer drivers and calling acceleration functions (ioctls) provided by the framebuffer drivers. 2) doing all the work themselves. I want to make a TinyX server that uses these accelerated functions. Now, what's my best option: Option A) Hack the kdrive/XFbdev source to call accelerated functions where possible. The rendering functions provided by the Geode driver are: Gal_set_solid_pattern Gal_set_mono_pattern Gal_set_raster_operation Gal_pattern_fill Gal_set_solid_source(unsigned long color Gal_screen_to_screen_blt Gal_screen_to_screen_xblt Gal_bresenham_line There are many other functions available, but since this is going in an embedded device, I'm not too worried about setup issues and much more concerned about how fast the thing is going to draw. Option B) Attempt to figure out what Keith Packard was doing with the other drivers in the kdrive directory, and modify the geode source code to match that. Suggestions/Comments? Alex Pavloff Software Engineer Eason Technology ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Geode KDrive
Hello folks. I have a National Semiconductor's Geode XFree86 4 drivers. These drivers can be run in two ways 1) sitting on top of National's Linux Framebuffer drivers and calling acceleration functions (ioctls) provided by the framebuffer drivers. 2) doing all the work themselves. I want to make a TinyX server that uses these accelerated functions. Now, what's my best option: Option A) Hack the kdrive/XFbdev source to call accelerated functions where possible. The rendering functions provided by the Geode driver are: Gal_set_solid_pattern Gal_set_mono_pattern Gal_set_raster_operation Gal_pattern_fill Gal_set_solid_source(unsigned long color Gal_screen_to_screen_blt Gal_screen_to_screen_xblt Gal_bresenham_line There are many other functions available, but since this is going in an embedded device, I'm not too worried about setup issues and much more concerned about how fast the thing is going to draw. Option B) Attempt to figure out what Keith Packard was doing with the other drivers in the kdrive directory, and modify the geode source code to match that. Option C) Say fuggedaboutit, and just use the Xfbdev server as is, because its not going to be much faster. Suggestions/Comments? Alex Pavloff Software Engineer Eason Technology ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Geode KDrive
Around 16 o'clock on May 20, Alex Pavloff wrote: Option B) Attempt to figure out what Keith Packard was doing with the other drivers in the kdrive directory, and modify the geode source code to match that. That's the right option -- you'll find several existing servers which layer on top of the basic fbdev/vesa servers to add a bit of acceleration. Kdrive contains 'kaa.c', which looks a bit like XAA, except that it accelerates only two operations -- solid fills and screen-screen blts. For modern applications, that's about all you'll need to have a respectable server. Take a look at the hw/kdrive/mach64 driver, it's layered on vesa, but doing much the same on top of fbdev is also possible. If the geode provides a VESA bios, you'll want to use the vesa layer instead of fbdev as that can support RandR while fbdev provides only a single size. Option C) Say fuggedaboutit, and just use the Xfbdev server as is, because its not going to be much faster. For screen sizes over 800x600 and depths over 16 bits, you really need screen-screen copies to make a reasonable X server. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
