OK sorry, I'll slow it down a notch:
Warning: only vagule related to the post topic. Rampant Linux-babbling ahoy!
There are a dozen ways to do everything in Linux. That is simultaneously it's greatest plus and minus. Heaps of choices, but steep learning curve and lots of docs to wade through.
Getting video out to a screen is no different. The three most common choices available via MAME (and AdvanceMAME) are:
1) XFree86/Xorg/X-Windows:
This is the most common GUI for Linux. Most people consider this the typical "Linux Desktop", and equate it with GNOME, KDE, etc. XFree86 (and it's forked successor, Xorg) are big, bloated and slow. Not bad on high-end machines, but not advised for dedicated setups. Sometimes this is also called "X-Windows" or just "X".
"X" needs video drivers, much like Windows does. X is open source, and as such only supply open source drivers due to licensing reasons (and that many video card companies will not release specs to open source driver writers for one reason or another - which I won't get in to here).
Under X, you can use various libraries to spit out MAME video information. This is EXACTLY THE SAME in Windows (before anyone says "why is it so complex?"). Windows gives you the choice of Direct3D or DirectDraw. Likewise under Linux you can choose X11 and SDL (2D only) or OpenGL (3D, but we only use the 2D part just like MAME+Direct3D). Exactly the same theory here as in MS Windows.
For OpenGL to work, you need (surprise surprise) OpenGL drivers. Again, more complexity, depending on your level of linux knowledge. Just like with MS Windows where you need to install the latest Nvidia drivers for Direct3D to work, the same applies here. However Linux and it's varied nature mean it's difficult to supply a "ready-to-go" driver that will support EVERY card/motherboard/system/kernel combination. As such, you need your kernel headers installed to help the driver figure out how to communicate with your system. Not friendly, but Linux is about choice over ease of use.
So, enter the other two options:
2) SVGALib:
Based on the old "VGALib" (ie: Video Graphics Array Library) this is a set of libraries and drivers for fast 2D video output direct from a commandline console. The best thing is SVGALib is completely independant of X. You don't need to install X at all, saving you megabytes of disk space as well as system memory. I use SVGALib in my cocktail cabinet, and my linux kernel and associated tools eat as little as 10MB of system memory when running. That's about 100MB less than Windows and/or X-Windows ever could. I actually run my cocktail cabinet on 512MB of physical memory, and absolutely no swap!
SVGALib merely needs to be installed (easiest way to do this is via the native package-management tools supplied with your choice of Linux distribution) and told what maximum and minimum frequencies of the attached monitor are in it's config file. Then, just use advcfg and advv to set and select video modes. The steps for doing this are very clearly outlined in the AdvanceMAME docs.
SVGALib currently is 2D-hardware-accellerated only. It can do 3D, but only in software. The beauty here is that 2D specifications chip-to-chip don't change much between card upgrades. The 2D technology used in the old RivaTNT cards is almost the same as that used in modern GeForce7800 cards. Ditto for other brands. As such, open source drivers for SVGALib are quite simple, and bundled with the package. No need to download extra drivers post-install like you would have to with X-Windows, or even Microsoft Windows. I use a standard SVGALib 1.9.19 release in my cabinet, and simply tell the software to autodetect my card. It correctly detects it as a "Radeon" (model doesn't matter, again because 2D hardware on all Radeons are identical) and "just works".

Best of all, SVGALib gives TOTAL programmability of video modes to the hardware. This is kind of dangerous, because anybody can feed modes to their monitor that it doesn't support, which can cause hardware damage. Again, see the comments regarding range of choice versus ease of use.
3) FBDev:
This is the native "Frame Buffer Device" in the Linux Kernel. For all intents and purposes, you can consider it similar in nature to the SVGALib project, with appropriate 2D accelleration for standard FrameBuffer devices (ie: Video Cards).
Often in modern Linux distros, FBDev support is built-in to the kernel, so no need to even install anything at all. Have a working commandline Linux installed (no X needed), and you're good to go. The downside is that some of the minimum pclock values are written into the code and are not configurable. As such, you may or may not require a recompile of the standard modules included in your kernel to make very low-res modes work properly on new hardware. For me, that makes SVGALib a preferred choice.
So, that's a whole bucket of info there. I don't know if it helps anyone or not.
Linux, due to it's highly customisable nature is a fantastic for cabinets. The problem is it is VERY difficult to write a one-size-fits-all solution. Projects like AdvanceCD, KnoppixMAME, etc all try, but outside of writing an whole distro complete with wizard to select your EXACT type of monitor, controls, etc it is nigh impossible. There will always need to be a level of customisability for cabinets, and as such requires some basic knowledge of how to configure the OS and associated tools that you've chose. That in itself pretty much slates Linux for use only by people who know how to use Linux. Not really a solution at all.

But, if you're willing to put in the time, sites like EasyMAMECab and Whammocade have heaps of Arcade-specific info for new users, and there are dozens of other sites (as well as the documentation) for general Linux setup.
I've been using Linux since 1996 (converting my entire business and home setups to 100% Linux 2 years ago), so I tend to forget exactly how long I've been doing this, and how long it's taken me to get to where I am now. But everything I know comes from documentation. The information is not hidden, nor expensive. But it does take time.