Due to a bug, the XFree86.org official release code does not support scandoubled modes for example, 320 × 240 on Geode.. The National Semiconductor server does work, but it doesn’t suppor
Trang 1FontPath “/usr/X11R6/lib/X11/fonts/Speedo/” FontPath “/usr/X11R6/lib/X11/fonts/Type1/” FontPath “/usr/X11R6/lib/X11/fonts/CID/” FontPath “/usr/X11R6/lib/X11/fonts/75dpi/” FontPath “/usr/X11R6/lib/X11/fonts/100dpi/” EndSection
Section “Module”
Load “extmod”
Load “dbe”
Load “dri”
Load “glx”
Load “record”
Load “xtrap”
Load “speedo”
Load “type1”
EndSection
Section “InputDevice”
Identifier “Keyboard0”
Driver “keyboard”
EndSection
Section “InputDevice”
Identifier “Mouse0”
Driver “mouse”
Option “Protocol” “auto”
Option “Device” “/dev/mouse”
EndSection
Section “Monitor”
Identifier “Monitor0”
VendorName “Monitor Vendor”
ModelName “Monitor Model”
HorizSync 31.5 - 50.0
VertRefresh 50.0 - 75.0
EndSection
Section “Device”
#Option “SWcursor” # [bool]
#Option “HWcursor” # [bool]
#Option “NoCompression” # [bool]
#Option “NoAccel” # [bool]
#Option “TV” # [str]
#Option “TV_Output” # [str]
Trang 2#Option “TVOverscan” # [str]
#Option “ShadowFB” # [bool]
#Option “Rotate” # [str]
#Option “FlatPanel” # [bool]
#Option “ColorKey” # i
#Option “OSMImageBuffers” # i
Identifier “Card0”
Driver “nsc”
Option “NoAccel” “True”
VendorName “Cyrix Corporation”
BoardName “5530 Video [Kahlua]”
BusID “PCI:0:18:4”
EndSection
Section “Screen”
Identifier “Screen0”
Device “Card0”
Monitor “Monitor0”
DefaultDepth 16
SubSection “Display”
Depth 16
Modes “1024x768” “800x600” “640x480” “400x300” “320x240” “320x200” EndSubSection
EndSection
There are many good reasons to switch to using XFree86 4 if you can, including:
■ Xv and DGA accelerated graphics support
■ An end to the need to specify weird virtual screen sizes (the Option Display-Compression setting achieves this)
■ More flexible server options
■ The default video modes have “friendlier” syncrates than the 3.x server
■ Translucent mouse cursors
Now, that’s only half the picture Due to a bug, the XFree86.org official release code does not support scandoubled modes (for example, 320 × 240) on Geode I have generated a patch for this bug If you’re interested in the gory details, you can find my
original posting on the topic, with an explanation of the problem, at http://www.mail-archive.com/devel@xfree86.org/msg00455.html Here’s the patch:
Trang 3- Begin patch for disp_gu1.c
130a131,135
> /*
> * Bugfix to gfx_is_mode_supported to fix problems with doublescan modes
> * Lewin A.R.W Edwards <[EMAIL PROTECTED]>
> */
>
839d843
<
840a845,850
> int tmp_yres;
>
> tmp_yres = yres;
> if (DisplayParams[mode].flags & GFX_MODE_LINE_DOUBLE)
> tmp_yres = tmp_yres / 2;
>
842,843c852,853
< (DisplayParams[mode].vactive == (unsigned short)yres) &&
< (DisplayParams[mode].flags & hz_flag) &&
-> (DisplayParams[mode].vactive == (unsigned short)tmp_yres) &&
> (DisplayParams[mode].flags & hz_flag) &&
850a861
>
878a890
>
- Begin patch for nsc_gx1_driver.c
150a151,155
> /*
> * Minor patches to allow support of low-res video modes
> * Lewin A.R.W Edwards <[EMAIL PROTECTED]>
> */
>
475c480
< { NULL, 25175, 135000, 0, FALSE, TRUE, 1, 1, 0 };
-> { NULL, 10000, 135000, 0, FALSE, TRUE, 1, 1, 0 };
937c942
< minHeight = 480;
Trang 4-> minHeight = 200;
1850c1855,1856
< if (MemIndex == -1) /* no match */
->
> if (MemIndex == -1) /* no match */
2363a2370
>
- Begin patch for nsc_gx2_driver.c
145a146,150
> /*
> * Minor patches to allow support of low-res video modes
> * Lewin A.R.W Edwards <[EMAIL PROTECTED]>
> */
>
474c479
< { NULL, 25175, 229500, 0, FALSE, TRUE, 1, 1, 0 };
-> { NULL, 10000, 229500, 0, FALSE, TRUE, 1, 1, 0 };
911c916
< minHeight = 480;
-> minHeight = 200;
Using my patched driver enables 400 × 300, 320 × 240 and 320 × 200 graphics modes, which are useful if you need to play VideoCD or other low-resolution movie content on a Geode platform However, you will still have to contend with the fol-lowing issues:
■ The NSC driver does not, apparently, fully support autoprobing This means that running XFree86 -configure will not generate a completely valid XFree86Config file (it will “kinda” work, but it won’t give you a full range of resolutions and will require some manual tweaking)
■ It appears that the Geode, or at least the X driver for it, doesn’t support DDC so the monitor syncrates in an auto-generated XFree86Config will be arbitrary
Trang 5■ If you’re running with display compression enabled, you may see minor video glitches onscreen, particularly if your application writes directly to display memory This phenomenon appears to be a momentary loss of sync, like a skipped v-sync pulse, and it is yet another of the problems caused by the ridiculous “video compression” feature of the CS5530 The line:
Option “NoCompression” “True”
in the Device stanza in your XFree86Config file fixes this
■ UI rotation is supported using the Option “Rotate” “CW” or Option “Rotate”
“CCW” switches However, these will fail catastrophically unless you also use Option “ShadowFB” “true” This has a fairly severe performance downside and I don’t recommend it
■ Flat-panel support appears to be partly broken, at least on the PCM-5820 with current BIOS versions If you need to use a direct-connect parallel or LVDS LCD, then for the time being you are probably best off using the VESA driver Neither the vanilla XFree86 driver nor my patched driver will work correctly on most of the LCDs I have tested The National Semiconductor server does work, but it doesn’t support scandoubled video modes (Note, by the way, that you need to specify Option FlatPanel True if you are using XFree86 4.x with an LCD system)
■ The nsc_drv.o driver does not correctly save/restore the entire video subsys-tem state with some BIOS versions This makes it impossible to switch from
X to a different virtual console It also means that the system will lose sync and go into an undisplayable video mode if you exit X There is no work-around for this issue at this time; use XFree86 3.x if this is a problem for you This problem is known to exist on the PCM-5820 (all 1.x BIOS versions), Wafer-582x (all versions) and the e-valuetech EBC-3410 It does not affect the EBC-5410 with the BIOS versions I have tested to date
Trang 64.7.5 Hybrid and Unusual Interfaces
Choosing a graphics interface method in Linux is quite complicated, because many
of your possible options overlap, and certain combinations of them can coexist hap-pily on the one system For example, it’s possible for either svgalib or X to run on top
of the framebuffer device; in fact, embedded ARM-Linux systems with LCDs (such
as PDAs) are almost universally implemented with an X server running on top of the appropriate framebuffer driver Even though X is using the framebuffer, there’s noth-ing to stop your application from writnoth-ing into video memory directly and only usnoth-ing
X for features that absolutely require it
I’d like to share with you, briefly, two apparently little-known methods of imple-menting a GUI, neither of which are talked about very frequently (if at all) I’ve had success with both of these in commercial products, and I feel that they saved me considerable time in the applications I was implementing Each one solves a very dif-ferent set of problems
My first suggestion is to include an embedded web browser and a simple web server on your appliance, and implement as much as possible of the user interface
as web forms processed (through the web server) by a backend program The great thing about this method is that you automatically get “free” remote control of the appliance over a TCP/IP network connection, if available This technique doesn’t work well for all types of appliances (for instance, I wouldn’t try it with something like a digital video recorder), but it does work exceedingly well for implementing the configuration front-end on an appliance that spends most of its time doing nonin-teractive things An example of this would be an electronic advertising sign sort of application; most of the time, it’s running movies and playing still images, but oc-casionally the user needs to twiddle the configuration Another good example is a machine on a factory floor, controlling some largely automated process such as count-ing or sortcount-ing; you might want to have a local console so that operators can perform occasional maintenance functions directly at the machine, but mostly you will want
to operate it remotely
Trang 7One suitable backend for this type of system is the industry-standard Apache web server included with most Linux distributions (including Fedora) Although it’s rather overkill for the type of application we’re discussing, it’s easy to use, it is easy to write compatible CGI modules in many different languages, and the server is pre-integrated with the OS distribution, which make it an obvious starting point, if nothing else
Choosing a web browser to run locally is a bit more challenging Mozilla/
Netscape is a grotesque leviathan; it’s slow to start and has an enormous RAM and disk footprint It is extremely sluggish on Geode, mostly due to the slow performance
of X in general Opera is a possibility, but it’s a commercial product and it still doesn’t have wonderful performance For the application we have in mind, I recommend
using either Dillo http://www.dillo.org/, or eLinks http://elinks.or.cz/ Dillo is a small,
reasonably fast X-based browser, and it’s particularly good at rendering pages in a cosmetically similar fashion to the “big” browsers This may be important in applica-tions where the browser will be called upon to render external content in addition
to the local configuration pages However, if that feature isn’t overridingly important
to you, I suggest eLinks as a better choice eLinks can run either on the standard framebuffer console, or as an X application In either case, it uses its own font-ren-dering engine, which leads to cosmetically different presentation than you would see with a more conventional browser However, it does support a large number of useful features—secure connections, support for forms, some scripting functionality, and so
on Since it doesn’t run with an X event model, it also lends itself admirably to being adapted for use in embedded environments that don’t have traditional input devices For example, in one application, I have adapted eLinks to use five pushbuttons for page navigation; two buttons scroll the page up and down, two buttons select “previ-ous link” or “next link” (amongst the hyperlinks on the currently visible page), and the remaining button enters the currently activated link Holding down that fifth button brings up a context menu that allows you to move forwards or backwards in the page history
My second suggestion contains rather a lot of cheating For a rather large project, I needed to implement a system that was able to run a few X applications and could also run an XFree86-based movie player application that needed to be able to change video modes and use hardware MPEG playback acceleration However, the device needed to
Trang 8present a slightly souped-up version of a proprietary GUI that was originally developed
on a much older product (The older product was OS-less; it ran on a fairly low-perfor-mance 32-bit architecture with very little operating system support)
It just so happened that the proprietary GUI portion of this code was already entirely extant in the older project, so I didn’t want to move it on top of an existing graphics library I eventually developed a hybrid sort of system The machine boots into XFree86, and launches my application To cut down on system resource usage, there is no window manager; the startup scripts simply spawn the X server, pause for
it to finish starting up, then launch my executable My program then obtains the starting address of video frame memory, and mmap()s it into its address space (in a similar manner to the framebuffer example code I described earlier) By making a few assumptions about video memory layout, it can run the exact same code used in the older OS-less product When it needs to provide a function that requires interaction with X, it simply spawns a subprocess; a movie player, web browser, and other similar
“high-level” applications are all provided
This ramshackle-sounding system actually works very well, and it allows the proprietary portions of the GUI to remain portable back to the older, non-PC-based versions of the appliance Furthermore, the main application doesn’t have to deal with Geode’s sluggish X performance
Quite possibly, neither of these suggestions exactly matches your system needs The point I’m trying to make here is that there is room for lateral thinking when choosing your interface It’s entirely possible to tailor your user interface technology
to the specific needs of the application you’re trying to implement
4.8 Infra-Red Remote Control in Linux Using LIRC
There are several sorts of applications where it may be useful to offer infra-red re-mote control capabilities The obvious example is a homebrew DVR (digital video recorder) or TV-top player box for video content downloaded off the Internet In an industrial or laboratory setting, however, there are other possible uses for IR con-trol For example, you may want to have your electronics in a sealed box to protect against environmental hazards (water, corrosive chemicals, etc) Your appliance may
be mounted somewhere difficult to reach Or you may simply want to prevent
Trang 9ran-dom passersby from tampering with equipment settings—authorized personnel with the appropriate remote control can still access these settings easily
Most super-I/O chips, including the Winbond W83977 on our Advantech board, include an IR decoding function, configurable either for bidirectional IrDA commu-nications or for receiving commands from CIR (consumer infra-red) remote controls Note that these two functions are very different, and are supported by completely dif-ferent software IrDA is a very complex bidirectional protocol; although some remote controls use IrDA, almost any consumer remote control you’re likely to acquire will use
a simpler consumer protocol, such as the Philips RC5 code set In this section, I’ll show you how to set up your SBC to receive the signals from almost any arbitrary remote control The specific remote I’m using in my worked example here is a generic cable
box controller supplied by Infrared Remote Solutions Inc http://www.infraredremote com/, part IRSI-07-15-01 A sample is shown in Figure 4-2.
Figure 4-2:
Example IR remote
Trang 10I chose this device to work with because it has the fewest buttons of any remote I own, thus making for a nice simple example For convenience, I will refer to the but-tons (from upper left to lower right) as 1, 3, W, A, S, D, and X—because this layout can nicely be emulated on a QWERTY keyboard with a roughly similar button lay-out You may prefer to use a universal remote, in which case you can simply pick an appliance type and model (say, Sony® DVD player) and follow the remote’s instruc-tion manual to set the universal remote to emulate the controller for that device This technique has the advantage of ongoing reproducibility; you can be fairly sure of being able to acquire a steady supply of an off-the-shelf universal remote—and even
if your specific model is discontinued, you will be able to switch to another model as long as it handles the same appliance types
Let’s begin with a thumbnail description of how an infra-red remote operates: The remote control itself consists of a key matrix, an application-specific micro-controller, and an IR LED When a key is depressed, the microcontroller generates
a sequence of bursts of carrier signal, typically somewhere between 30~40 kHz—in our case, 38 kHz The burst sequence encodes a button ID; these codes are arbitrarily mapped to appliance functions There are several common encoding protocols, and most of these protocols include some kind of subprotocol to differentiate between multiple devices of the same type
On the receiver side, it is normal to use an integrated IR receiver module as the front-end, rather than assembling something out of discrete components An exam-ple of the sort of component you would find here is the Vishay TSOP12xx or Sharp GP1U series of parts In general, these receiver modules consist firstly of an optical
IR filter and photodetector In the case of the Sharp and Vishay devices, the housing
is simply molded out of an IR-transparent resin Some older modules were
con-structed of metal with a small IR-transparent window at one end This hardware is followed by, at minimum, a bandpass filter centered on the nominal carrier frequency, and a demodulator circuit that turns the carrier frequency into a solid logic level, normally HIGH (or high-impedance) for no carrier, and LOW for carrier detected Most available detector modules have a little extra intelligence in them to reduce noise sensitivity by ignoring extremely short carrier bursts