Weekly Edition
Return to the Development page
| |||||||||||||
Announcing printerd
Tim Waugh has announced
(on May 10)
the existence of the printerd project, meant to be a new print spooling
subsystem for Linux. "It is a polkit-enabled D-Bus system service,
written using the GLib object system. Although modeled on concepts from
IPP (Internet Printing Protocol), printerd is not in itself an IPP
server. Its only interface is D-Bus, although the aim is to be able to
implement an IPP server on top of the D-Bus API as a separate
process. Having a D-Bus interface means that applications wanting to print
automatically get to use printerd asynchronously."
(Log in to post comments)
Announcing printerd Posted May 22, 2012 13:45 UTC (Tue) by cthart (subscriber, #4457) [Link]
What problems are they trying to solve?
Announcing printerd Posted May 22, 2012 14:04 UTC (Tue) by rfunk (subscriber, #4054) [Link]
The announcement says "it aims to be a modern print spooler for Linux." It looks like "modern" includes D-Bus as a high priority. "Having a D-Bus interface means that applications wanting to print automatically get to use printerd asynchronously."
I can guess that having a printing system not controlled by Apple might also be a goal, although printerd would still require CUPS drivers.
Announcing printerd Posted May 22, 2012 14:21 UTC (Tue) by aaron (subscriber, #282) [Link] Some reasons, off the top of my head:
Announcing printerd Posted May 22, 2012 15:11 UTC (Tue) by mbt (guest, #81044) [Link]
Not enough daemons? How long will it be before this code gets merged into systemd?
If all your users are sitting at seats around your single host, you don't need network transport for reaching printerd/systemd. It can even wake up your printer when you start printing.
Argh! With all these daemons around, we need an exorcism.
Announcing printerd Posted May 22, 2012 15:19 UTC (Tue) by nye (guest, #51576) [Link]
I hope you'll forgive the stupid question: why does this need to be a daemon at all? What gain is there from a constantly running process rather than an executable launched when required?
Announcing printerd Posted May 22, 2012 15:35 UTC (Tue) by drag (subscriber, #31333) [Link]
I suppose you have a way to manage the print spool centrally rather then trying to deal with lock files and whatnot to avoid race conditions when you have lots of programs kicking off print jobs simultaneously.
Normally I am happy to see new developments, but I personally really don't understand the point. The 'print spool' itself has never been much of a problem.
It's the printers themselves and the applications needed to properly support print jobs.
Like: I have to print labels in a automated manner on a Xerox Laser using PCL. Or a home label maker. Or if I want to use a Lexmark printer in Linux or the dozens and dozens of things that Linux tends to really suck at.
The task 'Add or remove pdfs from print spool' doesn't strike me as a problem that users had to overcome in the past. Other then the fact that the GUIs for selecting printers and printer features are miserable, tend to be missing controls, and have no consistency.
Announcing printerd Posted May 22, 2012 15:39 UTC (Tue) by gioele (subscriber, #61675) [Link]
> why does this need to be a daemon at all? What gain is there from a constantly running process rather than an executable launched when required?
From the dbus homepage:
> D-Bus […] makes it simple […] to launch applications and daemons on demand when their services are needed.
Announcing printerd Posted May 22, 2012 23:05 UTC (Tue) by lindi (subscriber, #53135) [Link]
From doc/TODO: "Service termination when no clients or jobs running".
Announcing printerd Posted May 22, 2012 16:14 UTC (Tue) by randomguy3 (subscriber, #71063) [Link]
> 1. Not enough daemons. (If history is a guide, printerd would run in addition to the various CUPS daemons, "just in case.")
Although printerd can be on-demand, due to the D-Bus interface. Or it could provide a cups compatibility layer.
> 6. Force everyone to go graphical/PDF, since we don't need to support receipt/invoice/check/line/Braille printers anymore.
Presumably applications where that is relevant wouldn't use printerd's D-Bus interface, but talk to (and require) cups directly.
Announcing printerd Posted May 22, 2012 22:01 UTC (Tue) by raven667 (subscriber, #5198) [Link]
> What problems are they trying to solve?
I don't understand that either. The announcement just has a list of buzzwords but doesn't explain to me the rationale behind this development or how it'll integrate with the system. I'm not sure how this is different from, improves upon or integrates with CUPS which is by far the most widely deployed and most supported printing environment (except for Windows native drivers but that has a non-portable design anyway).
It'd be useful to see a longer form article of the whys and wherefores by the authors of this software instead of the wild and misinformed speculation that is likely to occur given the lack of information.
Announcing printerd Posted May 22, 2012 23:22 UTC (Tue) by lindi (subscriber, #53135) [Link]
Being polkit-enabled means you can configure administration policies in a centralized place instead of separately for each service. I've seen places where people type root password to https://localhost:631/ to be able to add printers...
Announcing printerd Posted May 26, 2012 14:33 UTC (Sat) by jond (subscriber, #37669) [Link]
I often do that because the GNOME print wrappers around CUPS aren't very good. Actually I don't use https.
Announcing printerd Posted May 23, 2012 12:34 UTC (Wed) by nsoranzo (subscriber, #34668) [Link]
Tim replied to a similar question in his blog:
http://cyberelk.net/tim/2012/05/10/announcing-printerd/co...
Because CUPS finally 'just works' Posted May 22, 2012 14:28 UTC (Tue) by jmorris42 (subscriber, #2203) [Link]
It took quite a few years of pain to finally get to where CUPS is painless. So of course we must rip and replace it, it is the Linux way! Anything that works has to be replaced with something that doesn't, otherwise Microsoft wins. Or something.
Because CUPS finally 'just works' Posted May 22, 2012 16:18 UTC (Tue) by ms (subscriber, #41272) [Link]
Hmm, from my perspective, cups certainly does not "just work". Almost without fail, every time I want to print something I have to delete and recreate the printer in cups.
Because CUPS finally 'just works' Posted May 22, 2012 17:07 UTC (Tue) by jreiser (subscriber, #11027) [Link]
Another example where CUPS does not "just work": My PostScript printer with USB interface is driven by an Apple AirPort device, accessed over my local network via HP JetDirect protocol TCP port 9100. When my printer job does not succeed (PostScript error, paper out, pushing the Job Cancel button on the printer, ...) then "lpq" on my machine says "Printer is stopped", and indeed no progress will be made on any print job for that printer. So how do I restart the printer? No utility whose name starts with "lp" will do it. Then I try CUPS via http://localhost:631. On the page displayed by CUPS 1.4.8 (or following any of the links) I can find nothing about re-starting a stopped printer, print queue, etc. Rebooting my Linux machine will *not* do it. Answer: "cupsenable <printer_name>". This is such a gigantic failure of Usability!
Because CUPS finally 'just works' Posted May 22, 2012 17:33 UTC (Tue) by vivo (subscriber, #48315) [Link]
https://localhost:631
printers => administration => Set Default Options => Policy s/stop printer/abort job/
to restart a printer do it in maintenaince
Because CUPS finally 'just works' Posted May 22, 2012 17:38 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
> Then I try CUPS via http://localhost:631. On the page displayed by CUPS 1.4.8 (or following any of the links) I can find nothing about re-starting a stopped printer, print queue, etc.
It's in the "maintenance" drop-down list after you select "Printers" and then the name of your printer. Besides "cupsenable", this is also equivalent to:
> lpadmin -p $printername -E
The error behavior is also configurable with:
> lpadmin -p $printername -o printer-error-policy=retry-current-job
or by changing the ErrorPolicy line in /etc/cups/printers.conf.
This is for a more recent version of CUPS (1.5.2), and I'm not sure how well it translates to version 1.4.8. The maintenance drop-down, at least, has been around for quite some time.
Because CUPS finally 'just works' Posted May 22, 2012 18:57 UTC (Tue) by job (guest, #670) [Link]
The very idea of a web interface just to control your printer is laughable in my opinion. That interface belongs in the print dialog of your GUI, because that is where you are when you need it.
I normally just let gs speak directly to lp0, and use lpr/lpd to connect over a network. That does not give me all access to all the bells and whistles of modern printers, but it just works and it has worked for some fifteen years.
Disagree - web interface a GOOD idea. Posted May 22, 2012 19:41 UTC (Tue) by boog (subscriber, #30882) [Link]
It works as soon as you have CUPS. No need to wait for Gnome, KDE et to catch up and/or agree on things. Updated immediately with CUPS - the usual benefits of web apps.
Doesn't prevent a more traditional API also being used.
Moreover, the way printer and peripheral support for Linux is going (in the wrong direction as far as I can see), a general move to embedded web technologies is quite helpful.
Disagree - web interface a GOOD idea. Posted May 23, 2012 7:56 UTC (Wed) by rvfh (subscriber, #31018) [Link]
We need and HTML5 app that integrates into any desktop, even Android's.
Because CUPS finally 'just works' Posted May 23, 2012 11:44 UTC (Wed) by jengelh (subscriber, #33263) [Link]
>"lpq" on my machine says "Printer is stopped", and indeed no progress will be made on any print job for that printer. So how do I restart the printer? No utility whose name starts with "lp" will do it.
No, since lp* is out. But there is "cupsenable".
Because CUPS finally 'just works' Posted May 23, 2012 22:56 UTC (Wed) by jjs (guest, #10315) [Link]
lp* is still on my debian testing system.
Because CUPS finally 'just works' Posted May 26, 2012 23:23 UTC (Sat) by butlerm (subscriber, #13312) [Link]
>When my printer job does not succeed (PostScript error, paper out, pushing the Job Cancel button on the printer, ...) then "lpq" on my machine says "Printer is stopped", and indeed no progress will be made on any print job for that printer. So how do I restart the printer?
Whatever the rationale is, the default for this on CUPS could hardly be more unfriendly. This sort of thing makes it look like a full employment program for system administrators. No wonder people want to replace it.
Announcing printerd Posted May 22, 2012 14:31 UTC (Tue) by nix (subscriber, #2304) [Link]
I'd not mind this increasing emphasis on D-Bus if there was a sane way to allow D-Bus session bus connections to be tunnelled over the network. Unfortunately it seems we currently have two possibilities:
- local AF_UNIX sockets with randomly-assigned names in a fixed directory, with a name exported via an environment variable (the default). Local system only, you're on a remote system? Sucks to be you.
- remote IP connection, not really per-session as there is no automatic port assignment, SSH forwarding or anything else. i.e. you can say
<listen>tcp:host=localhost,bind=*,port=10315</listen>
in session.conf, but what you cannot say is 'assign a port automatically, and export it in an environment variable', let alone 'get SSH to forward-and-proxy a connection to the dbus session bus', which would allow a secure session bus across the network. This is not rocket science -- it's the preferred way of handling X connections -- but as far as I can see D-Bus is incapable of it. Am I wrong?
(Obviously doing this securely would involve -- fairly trivial -- changes to OpenSSH as well.)
Announcing printerd Posted May 22, 2012 16:22 UTC (Tue) by randomguy3 (subscriber, #71063) [Link]
That would be nice, but for most of its uses, you don't want it running over the network. Consider upower or udisks, for example, which control inherently local operations. It's not as though they replace something network-transparent, either. If you want to operate on a machine, run the application on that machine (which you can do with ssh). X-over-ssh is really a different thing, as it's about allowing interaction with graphical applications on a remote machine, the same way normal SSH works for console programs.
In the case of printerd, I think it's meant to be a purely local printing framework. If you want a print server, run Cups. Or Samba. printerd can then make use of either of those servers, but applications only talk directly to the local printerd (in the same way they might talk directly to a local character device in /dev, say).
And the announcement does suggest that there will be an IPP interface along soon, which is the right way to do printing over the network, really.
Announcing printerd Posted May 23, 2012 12:28 UTC (Wed) by krake (subscriber, #55996) [Link]
"This is not rocket science -- it's the preferred way of handling X connections -- but as far as I can see D-Bus is incapable of it. Am I wrong?"
Can you explain how SSH can be used to forward Unix sockets other than X11's?
I have been looking for that for years but never found any example on how to do that.
Announcing printerd Posted May 24, 2012 0:28 UTC (Thu) by nix (subscriber, #2304) [Link]
You can't forward AF_UNIX sockets with OpenSSH generally :( like I said, doing this properly requires changes to OpenSSH too.
Announcing printerd
Announcing printerd Posted May 28, 2012 13:01 UTC (Mon) by nix (subscriber, #2304) [Link]
Probably. After all, socat can do anything. Downside: reading the manual requires dark rites first to prevent your brain dribbling out of your ears. It's the Emacs of netcats.
forwarding unix-domain sockets over ssh [was: Announcing printerd] Posted May 30, 2012 1:35 UTC (Wed) by dkg (subscriber, #55359) [Link] Yes, you can certainly use socat with ssh to forward UNIX-domain sockets.
Announcing printerd Posted May 23, 2012 14:57 UTC (Wed) by Jluis (subscriber, #28564) [Link]
There has been, and still is, a tool to acces a remote dBus see: http://gabriel.sourceforge.net/howto.html. I remember that it was used by some developers in the openmoko comunity
Announcing printerd Posted May 24, 2012 0:34 UTC (Thu) by nix (subscriber, #2304) [Link]
Interesting! I'll have a look at that...
Other IPP servers? Posted May 22, 2012 15:39 UTC (Tue) by bkw1a (subscriber, #4101) [Link]
Is CUPS currently the only IPP server available for Linux? I looked around for others a while back, but couldn't find any. It might be fun to have a lightweight IPP server to play with.
Old school Posted May 22, 2012 15:53 UTC (Tue) by kragil (subscriber, #34373) [Link]
Starting a new Glib project in C?
I know we all love C, but wouldn't have Vala been the better(as in more productive) choice?
Old school Posted May 22, 2012 18:43 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> I know we all love C
Speak for yourself please.
Announcing printerd Posted May 22, 2012 16:11 UTC (Tue) by randomguy3 (subscriber, #71063) [Link]
I'm guessing that the purpose of this is to be a "super-lightweight cups" for the common case where you want to print (a) infrequently and (b) to a fairly standard page printer (ie: not a receipt printer or anything). Running over D-Bus means it can be asynchronous and started on-demand, so avoiding using resources when not needed.
It will presumably be able to talk to IPP servers (via the relevant cups driver?), which might either run on the local machine (if you sometimes have more demanding requirements, like receipt printing) or on a remote machine (particularly in businesses, for example).
The issue, of course, is the transition period, where everyone will have to support everything. The announcement suggests that there will be a lightweight IPP server available at some point, which could be used to support CUPS-only applications (but negates the on-demand part of printerd), but applications using printerd's D-Bus interface will also have to support cups (or one of its compatibility modes, like lpr) directly to work on systems that don't have printerd.
Announcing printerd Posted May 22, 2012 16:56 UTC (Tue) by drag (subscriber, #31333) [Link]
> I'm guessing that the purpose of this is to be a "super-lightweight cups" for the common case where you want to print (a) infrequently and (b) to a fairly standard page printer (ie: not a receipt printer or anything).
I don't understand the point of writing less capable software just so that when somebody needs to be able to do what is relatively easily done in any other OS they must rip out your software and/or reconfigure their OS.
> It will presumably be able to talk to IPP servers (via the relevant cups driver?),
Typical 'cups driver' is just a postscript description file.
Postscript is a programming language that is used to instruct the printer on how you want you page printed. Cups will take the postscript from your application and then insert additional instructions to it based on the PPD file (aka 'driver') and your configuration dialogs. Instructions on how to handle ink, line speed, stapling, duplex, etc etc.
This is why you need things like Ghostscript, because CUPS must have the ability to tear down postscript 'documents' and then rebuild them for specific printer models.
Then, of course, there are a large number of printers that do not support postscript, proprietary psuedo-ascii line/serial printers, or printing tasks that require other languages like PCL.
On top of all that modern printers are designed to be really stupid. They tend to no longer understand proper printing languages. Instead they are little more then over-glorified USB accessories were you have a proprietary (as in printer-specific) daemon that is able to take the postscript/pcl/etc instructions and transform them to the device-specific instructions necessary to operate the printer head and emulate a traditional printer device.
All and all even relatively 'basic' printing tasks tend to be fiendishly complicated and require a heavyweight solution.
So unless printerd can replace CUPS in it's entirety there is no point in having it do anything except just being a spool manager that replaces some fraction of CUPS functionality.
Announcing printerd Posted May 22, 2012 19:23 UTC (Tue) by butlerm (subscriber, #13312) [Link]
> Cups will take the postscript from your application and then insert additional instructions to it based on the PPD file (aka 'driver') and your configuration dialogs. Instructions on how to handle ink, line speed, stapling, duplex, etc etc.
This is evidence of a dedicated printer mentality. Why in the world should a typical user configure a 'printer' in order to get a specific print job to print the way he wants it to? Users should have the ability to control all of that from within some sort of print dialog in the application.
>This is why you need things like Ghostscript, because CUPS must have the ability to tear down postscript 'documents' and then rebuild them for specific printer models.
A much saner system for graphical printing would be for applications to use some combination of shared libraries to discover what printers are available, what properties they have, allow the user to configure the specific print job, render (ultimately) through a standard API directly to a printer driver loaded in-process, and send the output of the printer driver to the spooler on a local or remote system.
Then the system wouldn't be in the position of rendering to some baroque programming language, and loading and reinterpreting it into something printer specific. X style process separation for the printer driver could be kept if necessary, but the idea that Postscript should be the lingua franca for communication to a printer driver is positively perverse.
Announcing printerd Posted May 22, 2012 20:40 UTC (Tue) by drag (subscriber, #31333) [Link]
> This is evidence of a dedicated printer mentality. Why in the world should a typical user configure a 'printer' in order to get a specific print job to print the way he wants it to? Users should have the ability to control all of that from within some sort of print dialog in the application.
Configuring a printer from a print dialog is exactly what I am talking about.
You select color quality, line quality, print speed, stapling, collation of reports, and all that stuff. A person must decide this when printing.
That's 'configuring'.
If you want to be able to print anything other then plain single-sided black and white documents then the ability to edit postscript documents and insert the proper printer-specific control sequences on the fly is a absolute requirement.
Depending on the printer you can send usually postscript directly to it. Over a parrellel port or USB port or over IPP connection. It may need to be rendered into USB control sequences for cheapy ones using a proprietary daemon.
> A much saner system for graphical printing would be for applications to use some combination of shared libraries to discover what printers are available,
So you want to distill the functionality provided by CUPS and Ghostscript (and related filters, tools, and programs) into application libraries and then load that into each and every application? How would that work out well?
> Then the system wouldn't be in the position of rendering to some baroque programming language, and loading and reinterpreting it into something printer specific.
So instead you want each and every application will be in the position of rendering to some baroque programming language, and loading and reinterpreting it into something printer specific.
That seems completely ass-backwards. Typically the OS wants to make things easier for programmers to do by providing common functionality instead of making it worse...
Announcing printerd Posted May 22, 2012 21:21 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
> So instead you want each and every application will be in the position of rendering to some baroque programming language, and loading and reinterpreting it into something printer specific.
That's actually almost exactly what is done today. the "baroque programming language" is postscript.
but we've seen what happens when every program needs to adjust it's document to the printer in question, the result is the windows printing mess where loading a different printer driver can change your document layout drastically.
Announcing printerd Posted May 23, 2012 1:23 UTC (Wed) by drag (subscriber, #31333) [Link]
> That's actually almost exactly what is done today. the "baroque programming language" is postscript.
Of course. That's why I _said_ it.
Postscript, in this context, cannot be thought of as a document format. It's a printer control language.
It's wrong to treat it like it's a document. It's a scripting language that instructs printers on how to print out documents. And as such it needs to be edited on the fly and based on the preferences of users in different manners for different printers.
Which is why it's important that you use a centralized program to manage this as much as possible. The program should just tell the daemon that 'I want low quality color collated front to back with pages 1-5 stapled together' and have the system deal with it as much as possible.
> but we've seen what happens when every program needs to adjust it's document to the printer in question, the result is the windows printing mess where loading a different printer driver can change your document layout drastically.
That's not surprising since each printer can be drastically different and different PPD files (aka 'printer drivers', aka 'postscript printer description' files) expose different capabilities.
Unless your program can change the document to suite the printer then it's just a guessing game on the part of the user as to how it's going to look when printed. However, obviously you don't want to force every application to be a desktop layout suite. So therefore you want the system to handle as much as the complexity as possible for applications that don't need it.
This is why you will always needs CUPS or something just as complex to replace it. You can't get away from it. Printing is a huge pain the ass.
Announcing printerd Posted May 23, 2012 19:48 UTC (Wed) by butlerm (subscriber, #13312) [Link]
My main criticism here is that Postscript is extraordinarily inefficient, insecure, and awkward as a standard interface from applications to printers and print spoolers. Because it is Turing-complete, a print job can take an infinite amount of time to run, and it is difficult to manipulate. Not only that, most actual Postscript interpreters are riddled with subtle bugs.
There is nothing in principle more difficult in rendering to a high resolution printer than in rendering to a display. For a wide variety of reasons, it is uncommon to require applications to generate Postscript fragments to display anything on the screen. Virtually every graphical application uses some sort of internal or library provided rendering API to display output on the screen, why should it use a different one to generate output for printing?
As a consequence of this common architecture, a Turing-complete programming language like Postscript is massive overkill for contemporary printer interface. PDF is much better (because it is not a programming language), but it tends to be a rather inefficient processing format as well.
A high performance page rendering interface should be based on a binary wire protocol vaguely similar to X, or a serialized version of OpenGL. PDF is more than a little inefficient by comparison. Contemporary display devices render hundreds of extraordinarily complex scenes per second.
Is there any fundamental reason why a printer driver can't be as efficient? Or why we shouldn't prepare for a world where nearly all page rendering is handled on the host system rather than by a ridiculously underpowered, buggy, and resource impaired piece of firmware on the printer?
Announcing printerd Posted May 23, 2012 20:30 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
> As a consequence of this common architecture, a Turing-complete programming language ... is massive overkill for contemporary printer interface. ... A high performance page rendering interface should be based on ... a serialized version of OpenGL.
Modern OpenGL (with shaders rather than fixed-function pipeline stages) essentially _is_ a Turing-complete programming language. For similar reasons, I don't think non-Turing-completeness is a reasonable requirement for any rendering API, and for printing I'd actually prefer something like a scene graph with attached shader programs. Naturally, as with rendering for the display, the shaders would be subject to various resource limitations, including a limit on runtime. It should be possible to rasterize the print job via commonly-available embedded, OpenGL ES-capable GPUs.
> Or why we shouldn't prepare for a world where nearly all page rendering is handled on the host system rather than by a ridiculously underpowered, buggy, and resource impaired piece of firmware on the printer?
A network-attached printer ought to be able to perform its own rasterization, to conserve I/O. For printers designed to be connected only to a host PC, however, I'd just as soon standardize on a simple raster-based printing protocol and do the heavy lifting on the host--ideally with GPU acceleration.
Announcing printerd Posted May 24, 2012 0:26 UTC (Thu) by nix (subscriber, #2304) [Link]
Shaders?! You do realise that most printers are used mostly to print text, or bitmap representations of text, and that rendering text via shaders is insanely resource-expensive?
Like it or not, there's going to be either a bitmap or a vector language (or, more likely, both) in any plausible printer for a very long time to come.
Announcing printerd Posted May 24, 2012 2:53 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
I'm talking about vertex and fragment shaders, in OpenGL terms, not generating text via shader programs. The scene graph would include the text as references to glyphs, and any required bitmaps in the form of textures. The shaders would be handling transparency, gradients, smooth scaling, and other visual effects, just as with rendering to a display.
Announcing printerd Posted May 24, 2012 8:30 UTC (Thu) by butlerm (subscriber, #13312) [Link]
>A network-attached printer ought to be able to perform its own rasterization, to conserve I/O.
This is a nice benefit, but the problem is that in most cases it is a program of planned obsolescence for otherwise perfectly adequate printer hardware. Short of mid-range printer manufacturers adopting a standard for rasterizer plugin cards, host (or print server) based rasterization ought to be the most effective way to keep a decent printer from not so gradually turning into an expensive paperweight.
As an example, I have a ~$1K laser printer from a name brand manufacturer that is less than five years old that is in the habit of taking more than a minute to print single pages from innocent looking PDF files. Certainly any well written host based rasterizer could run circles around that.
>Modern OpenGL (with shaders rather than fixed-function pipeline stages) essentially _is_ a Turing-complete programming language.
OpenGL serialization was a poor choice for an example. Something more like a efficient serialization of the PDF rendering model was what I had in mind. A serialization of OpenVG might work nicely, but it appears to be a little too simple.
Announcing printerd Posted May 24, 2012 9:00 UTC (Thu) by pkern (subscriber, #32883) [Link] You really want to drive network-attached printers with rasterized input as well. It has the computing power of a toaster, the only plus is that it can start printing when it completed the image of the first page. PDF can have multiple layers and hence may overload a rasterizing printer easily. Even PCL XL is already too complex and certain outputs will cause the printer to take a walk. The only part that worries me about printers that really only take raster input is the fact that you then need to bother with uploading their firmware and the newest and greatest proprietary inventions of rasterization on-the-wire formats to reverse engineer.
Announcing printerd Posted May 24, 2012 18:35 UTC (Thu) by butlerm (subscriber, #13312) [Link]
> the only plus is that it can start printing when it completed the image of the first page.
If there isn't any serious way to generate and stream a PDF document one page at a time, PDF would seem to be a uniquely unsuitable format for the printing of large documents not already composed and linearized in PDF format in any kind of a hurry. Perhaps SVG Print would be a better long term alternative for that reason alone.
Announcing printerd Posted May 24, 2012 18:02 UTC (Thu) by jsanders (subscriber, #69784) [Link]
I think you are mistaken if you think PDF is not a programming language. PDF is just a packaged-up subset of PostScript, with some enhancements and conventions for adding metadata. It's true that PDF doesn't have the full freedom PostScript has (like being constrained to one page at a time), but it really is a programming language.
Announcing printerd Posted May 24, 2012 18:25 UTC (Thu) by jsanders (subscriber, #69784) [Link]
Oh, it turns out in my ignorance, PDF is much more of a subset than I thought... I thought it still had control structures, but they are not there.
Announcing printerd Posted May 22, 2012 16:57 UTC (Tue) by jimparis (subscriber, #38647) [Link]
I got a new printer this weekend, and after spending several hours wrestling with CUPS, was thinking that it was about time for someone to come up with a "*d" replacement.
Unfortunately, they're still using the CUPS backends, which are the part I'm having the most problems with. You'd think that printing to a networked Postscript printer would be a walk in the park, but it's turned out to be an ordeal. It's frustrating trying to debug, because one small problem means that your printer suddenly starts spewing ten pages of unrendered PDF before you run over and shut it off for the umpteenth time. I'm still working on trying to figure out the actual problem enough to report a bug, though...
Pros and Cons of PDF print queues? Posted May 22, 2012 18:34 UTC (Tue) by bredelings (subscriber, #53082) [Link]
I've been looking forward to PDF printing queues for a bit. My printer can print PDF, and PDF can express some things that PostScript cannot. So, hopefully this would allow those features to print directly, and remove some of the overhead of converting PDFs to PS before printing. All the articles I want to print are in PDF now, not PS.
As far as other formats, some current print queues already convert text to PS before printing. This is different than disallowing text -- text is still allowed, but it isn't sent directly to the printer. Whether the everything-is-a-PDF paradigm has enough benefits to offset the cost of converting all documents to PDF before printing is something I'm not completely sure about.
Pros and Cons of PDF print queues? Posted May 22, 2012 19:01 UTC (Tue) by job (guest, #670) [Link]
What can PDF express that PS can not? On top of my head I'd say PDF Forms or embedded Flash, but how could you possibly get a printer to make sense of that?
Pros and Cons of PDF print queues? Posted May 22, 2012 19:15 UTC (Tue) by alexl (subscriber, #19068) [Link]
What about actual transparency (alpha channels), blending operations like "over", and transparency groups.
Also, the fact that its not a general programming language, so you can't write a raytracer in a PDF is kinda nice on the server side.
Also, I think there is some metadata storage in PDF so that you can tell the printer things about how to print the document, etc.
Pros and Cons of PDF print queues? Posted May 22, 2012 19:22 UTC (Tue) by sfeam (subscriber, #2841) [Link]
The biggest items for me are:
- PDF can handle CJK and other large font sets without the hackish and painful workarounds required in PostSCript, which was designed assuming that an 8 bit character index was all you needed.
- PDF can handle alpha channel color. The PostScript work-around for the lack of alpha-channel support is to expand all the relevant areas into bitmaps with pre-merged colors rather than carrying forward overlapping vector-based elements with transparency. This works so poorly that I hesitate to even call it a work-around.
Pros and Cons of PDF print queues? Posted May 22, 2012 19:01 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
what is it that pdf can do that postscript cannot? I was under the impression that pdf was just a compressed and simplified postscript file.
the biggest overhead of converting between pdf and ps is the overhead of dealing with the compression.
Pros and Cons of PDF print queues? Posted May 22, 2012 20:17 UTC (Tue) by mgedmin (subscriber, #34497) [Link]
> I was under the impression that pdf was just a compressed and simplified postscript file.
You're mistaken.
The drawing commands in a PDF file are a (non-Turing-complete) subset of PostScript, though, so the mistake is understandable.
Pros and Cons of PDF print queues? Posted May 22, 2012 19:17 UTC (Tue) by drag (subscriber, #31333) [Link]
In order for PDF to perform the same function as PS then your printer system is going to have to have the ability to edit PDF files on the fly and insert printer-specific formatting.
Seems like a tall order.
I am guessing your 'PDF printer' really just uses some daemon already to convert the PDF to PS or some other control language that the printer understands. If it is a network printer then I suppose it runs a embedded CUPS daemon on Linux or some proprietary alternative to do the work.
Announcing printerd Posted May 22, 2012 23:55 UTC (Tue) by cmccabe (guest, #60281) [Link]
Problem: Linux doesn't have enough support for proprietary printers that don't speak postscript or IPP.
Solution: throw out all the common infrastructure and re-do it. If the infrastructure is shiny enough, nobody will notice that they can't actually print.
Brilliant. I expect a long time period during which the maintainers blame buggy printer drivers for the fact that nothing works under the new infrastructure, a la Pulse Audio.
Announcing printerd Posted May 23, 2012 0:46 UTC (Wed) by shemminger (subscriber, #5739) [Link]
The problem with printers is they are all non-standard, so having a pollyanna view of the world is useless. My Brother laser printer has been broken for months because the CUPS developers decided to send certain postscript which causes the printer to give up and print blank pages. Since the firmware can't be fixed, the problem gets pushed back to CUPS to not send the bad code.
Architecture astronauts take over Posted May 23, 2012 4:35 UTC (Wed) by nhippi (subscriber, #34640) [Link]
This really sounds like a project that is started on horribly wrong basis.
Instead of starting with declaring
1) what the problem is
They go and explain how it going to be great since they use dbus and gobject?
Sounds like one of the many cases where the needs of architecture takes over the needs of users.
Please take a deep breath before posting. Posted May 23, 2012 5:45 UTC (Wed) by martinfick (subscriber, #4455) [Link]
I would like to ask you (and others) to reconsider posting a comment like this in the future. I don't believe that the authors of this project are out to get anyone. You may have had frustrations with software before, we all have, but I doubt that this particular project is the cause of any of them so it seems missplaced to attack them. They just started a project to write some software they thought might be useful and they ask nothing of you. No one is asking you to appreciate what they are doing. If you don't like their ideas or software don't use them, but it just seems hurtful and disrespectful to put them down so quickly, those are people whom you likely know nothing about and have little to judge them by. We have little to judge you by too, do you want it to be a message like this?
This message isn't just aimed at you (so forgive me if it feels too strong of a response to your post). I just felt upset reading the many replies above which had somewhat angry tones and yours was the last one in the series. It has become more and more common here to direct such anger or contempt towards free software creators. These are people who are hopefully just sharing with you and others. As long as they are just sharing freely without trying to extort you in some way, or maliciously convince you to use their malware it feels wrong to attack them (even if their code or designs are flawed). I know that I would feel upset reading the reception that these authors are getting here if I were them, and I don't think they were even asking for a reception.
Please take a deep breath before posting. Posted May 23, 2012 7:35 UTC (Wed) by nhippi (subscriber, #34640) [Link]
Fair points. The authors are not out there to get anyone sure, but I think it would be better if they would improve the plumbing of existing solutions instead of starting something out of scratch.
Creating a competitor for a existing system disrupts Linux ecosystem while the transition is going on, and fragments Linux further if it fails to be clearly superior than the historic alternative. Yes sometimes that has to happen, but it is not a decision to be taken lightly.
I think people take too easily the route of having fun of creating their project from scratch using their favourite technologies (like gobject and d-bus) than to joining the existing project and working with their preferred methods to make existing project work better for everyone.
I guess it is a bit of fame issue as well. Nobody will get famous plumbing an existing free software project, while someone who creates a new project will be known as the author of the new project...
Let me bow to the unsung heroes of free software development: plumbers of existing projects.
Please take a deep breath before posting. Posted May 23, 2012 9:07 UTC (Wed) by dgm (subscriber, #49227) [Link]
You're putting the blame on the wrong people.
It's absolutely right -even critical- to create alternatives to existing projects. It ensures there's no single point of failure at any level, and that we don't get stuck too long because of evolutionary dead-ends.
The _problem_ starts when bigger projects (desktops and distros) push an immature alternative, sometimes for shady reasons. Sometimes is because of someone's agenda, but often is just a combination of stupidity and stubborness (we are all humans after all).
So, I salute and thank the developers for the effort they are putting into this, but distros and desktops better stay clear from it, at least until they can demonstrate that it brings something valuable to the table _and_ can take over the functions of whatever is being replaced.
Please take a deep breath before posting. Posted May 23, 2012 11:09 UTC (Wed) by intgr (subscriber, #39733) [Link]
Erm, as far as I can tell, the purpose of a project announcement is to introduce the project to other people. This blog article is incomplete on that front. My takeaway from that article is exactly the same as the grantparent poster's: they don't have a problem, but they're trying to solve it anyway. I don't think it's unreasonable to expect a project announcement to state what problems the project aims to solve.
Look at the announcement of systemd for example: http://0pointer.de/blog/projects/systemd.html -- when reading it, I immediately recognized a few of my pet peeves listed and understood the value of the project.
> If you don't like their ideas or software don't use them
It's not as simple as that. The author of this project is also a Fedora developer. I think that users have the right to complain when they see a distro going in a direction that they don't like.
Please take a deep breath before posting. Posted May 23, 2012 12:44 UTC (Wed) by kmike (guest, #5260) [Link]
>> If you don't like their ideas or software don't use them
> It's not as simple as that. The author of this project is also a Fedora developer. I think that users have the right to complain when they see a distro going in a direction that they don't like.
Exactly. I wouldn't be surprised to see printerd as the default in Fedora 19.
Architecture astronauts take over Posted May 23, 2012 7:19 UTC (Wed) by alexl (subscriber, #19068) [Link] Its *possible* that Tim Waugh, maintainer of printing in Red Hat since time immemorial and one of the very few long term active participants in the Linux upstream printing echosystem has made a mistake, and that some random commenter on LWN has a point to make. However, this seems more like a no-brain cheap complaint about the announcement text, making fun of some techical decissions with no apparent real thought behind it.Just because the announcement doesn't fulfill your wet dream about how a perfect project announcement should look, please don't assume that the people involved are complete idiots who have no idea about the problem they are trying to solve. It just makes you look bad. Smart people don't think others are stupid.
Architecture astronauts take over Posted May 23, 2012 12:07 UTC (Wed) by nye (guest, #51576) [Link]
I don't understand the hate that nhippi's comment seems to have provoked; so far as I can see it's an objective assessment of the facts - the announcement really doesn't give any indication of what the project is for, what it's aims are, why it even exists, or much of anything really.
(Your personal attack on the other hand I found offensive and obnoxious)
Architecture astronauts take over Posted May 23, 2012 13:31 UTC (Wed) by alexl (subscriber, #19068) [Link]
The complaints about the announcement are factual and not really the problem. The problem is saying things like:
"Architecture astronauts take over"
It might not be all that easy to understand what printerd is for from the announcement, but that doesn't mean you should jump to the wrong conclusions and flame the people doing the work about those.
Tim has been working on Linux printing for the last decade. To claim that he has no knowledge about the needs of users, or that he just does this so he can use dbus or gobject is ridiculous. He is one of the few people who actually work to make printing work in Linux, and what does he get for it? Flames by people who do not even understand the problem (although the lack of understanding is partly the fault of the announcement).
Architecture astronauts take over Posted May 23, 2012 14:49 UTC (Wed) by spaetz (subscriber, #32870) [Link]
One thing I'd have liked to learn from the announcement is how this relates to CUPS. Is it supposed to be bolted on to CUPS, replace CUPS (given the recent Linux-unfriendly turn that CUPS development seems to have taken, this would not be unwelcome news) or what? All it says, that CUPS drivers will continue to work.
Architecture astronauts take over Posted May 23, 2012 15:01 UTC (Wed) by alexl (subscriber, #19068) [Link]
CUPS will not be entirely replaced. It will still be what talks to the printer, picks the right drivers, manages the installed printers, etc.
printerd is more like a session print spooler. It lets you enumerate printers, submit jobs to them, etc. If the printer was a network (ipp) printer that supports pdf, or a cloud service like Google Cloud Print then everything will run without any instance of CUPS.
However, if you're printing to a local printer, or a printer attached to a print server (on linux) then printerd will hand the pdf over to CUPS, running locally or on the server.
Tim has a nicer explanation in an earlier blog entry:
Architecture astronauts take over Posted May 23, 2012 16:56 UTC (Wed) by cmccabe (guest, #60281) [Link]
Hi alexl,
CUPS already has support for being a print spooler. It already allows you to "enumerate printers, submit jobs to them, etc." What is printerd going to provide that CUPS does not?
Please keep in mind that another layer of software is another layer of bugs that we will all have to debug. Even the best programmers sometimes make mistakes. If there's no value add from the additional abstraction, then I would prefer to keep things simple.
I would love to see something take over from cups, but only if it provides the same features that cups provides. I'm not really interested in running the printer daemon version of "duelling banjos."
Architecture astronauts take over Posted May 23, 2012 18:42 UTC (Wed) by alexl (subscriber, #19068) [Link]
I'm aware of how CUPS work. And the link I posted explains this too.
For the case of a local printer printerd would just call out to the local cups daemon just like currently, and printerd would be nothing more than a frontend for cups with an API that is nicer for async code (ever tried to write async code using libcups?).
However, if you're not using a local printer, but rather some network printer or cloud service then having to have a local system-wide print spooler is completely unnecessary, and printd would just forward the job to the spooler on the remote server, working completely in the user session.
Running in the session has some advantages besides just needing less code. It also allows the spooler to do things like authenticate to the cloud service in a normal way, as its part of the user desktop session, rather than some system service.
Anyway, Tim knows this stuff better, and he posted a new blog entry: http://cyberelk.net/tim/2012/05/23/some-benefits-of-print...
Architecture astronauts take over Posted May 23, 2012 22:41 UTC (Wed) by cmccabe (guest, #60281) [Link]
To be honest, I really don't care about asynchronous printing. How can I say this in the most tactful way-- I care more about dusting my ceilings than I do about the fact that applications need to spawn an extra thread to print.
My printer is a USB printer. It requires a printer driver to work. A driver which, incidentally has not been updated or fixed in years, and is not officially supported by the distro. Luckily I know enough about the plumbing to know how I can get this thing to work. (Should "work" be in quotes?)
At work, there is an IPP printer which I mostly use. The time I spent setting it up in CUPS was about 5 minutes, including printing test pages and all that.
> Running in the session has some advantages besides just needing less code.
Again, I just don't care. I've never used a multi-seat Linux machine (and I've had 5 jobs where I used Linux, including one where we used it in the cloud.) I also don't see what fundamentally prevents CUPS from doing the same thing-- i.e., accepting or rejecting jobs based on the user id that submitted them.
So far, printerd has not proposed to solve any of the problems I have ever had. Of course, I'm just one user-- perhaps others will have different needs.
Architecture astronauts take over Posted May 23, 2012 23:02 UTC (Wed) by jjs (guest, #10315) [Link]
I read his articles, and am still uncertain of the benefits. CUPS talks fine to remote printers. He admits CUPS integrates with polkit. Right now I tell my app to print, answer the various questions (# of copies, printer, etc), and off it goes. I go back to my app,and sometime later the printer prints my work (asynchronous from my viewpoint).
So other than adding another layer between the application and CUPS, what does printerd do?
Architecture astronauts take over Posted May 24, 2012 7:05 UTC (Thu) by jku (subscriber, #42379) [Link]
"sounds like a project that is started on horribly wrong basis" -- this is how he starts. Maybe he intended to say what you said ("announcement doesn't give any indication of what the project is for"), but I'd say there is room for misunderstanding there... There's a world of difference with "there's not enough information to evaluate this project" and "this project started on the wrong basis".
It's true that the announcement should have come with a link to http://cyberelk.net/tim/2012/05/23/some-benefits-of-print... but lets not make that omission a larger issue than it is.
Announcing printerd Posted May 24, 2012 15:33 UTC (Thu) by njd27 (subscriber, #5770) [Link]
I have to say, I remote print over the network all the time, and I find writing a new print spooler without building network support in from the beginning to be a backward step. This is just like those wayland people all over again.
Announcing printerd Posted May 25, 2012 3:45 UTC (Fri) by quotemstr (subscriber, #45331) [Link]
You don't need network printing support. You can just print your document locally, walk over to the network printer, scan it there, then print another copy. It's _BETTER_ than old-fashioned network printing.
Or at least that's what the Wayland people taught me.
Announcing printerd Posted May 25, 2012 10:35 UTC (Fri) by dgm (subscriber, #49227) [Link]
Wrong. You bring your monitor with you down to the Xerox machine and copy _that_. I hate when people don't pay attention.
Now seriously: that's exactly what you have been doing for a few years now unless you limit yourself to Motif applications, because all popular toolkits draw on the client side and then send the pixmaps to the X display via XRender these days. Or at least that's what they told to me.
You betray your ignorance of wayland Posted May 25, 2012 11:55 UTC (Fri) by sdalley (subscriber, #18550) [Link] Ho, ho, very amusing. But you and the GP demonstrate that the Wayland people haven't been able to teach you anything at all. Remote display of an entire desktop (as opposed to an X window) is an orthogonal problem. See the Wayland FAQ:Is Wayland network transparent / does it support remote rendering?As far as existing remote X functionality is concerned, look at http://wayland.freedesktop.org/architecture.html , and then at http://wayland.freedesktop.org/xserver.html . You will see from this that the Xserver merely becomes another Wayland client. The intention is that nothing that X was able to do before (e.g. remote windows over the network) is going to be lost, because remote X clients can continue to connect to the X server just as they always have.
Strong words Posted May 25, 2012 14:28 UTC (Fri) by renox (subscriber, #23785) [Link]
And what you demonstrate is that you don't understand that 'project XYZ FAQ' is usually biased towards project XYZ..
Obviously Wayland devs would say that that Wayland won't create issues for using remote display in a WAN, in practice we will see: it's very possible that this will be a mess..
In a way, it *is* already a bit of a mess: NX isn't integrated in X as it should be IMHO.
Strong words Posted May 25, 2012 17:16 UTC (Fri) by sdalley (subscriber, #18550) [Link]
Sorry, I didn't mean to upset anyone. But I tend to have more confidence in the answers of those who designed the architecture, went to some trouble to document it, who've rolled their sleeves up and are actually doing the work, than in people who make snide potshots from the sidelines.
We all wish that the Linux desktop experience was better today. But what are your technical objections to Wayland? You admit that the current state of X is non-optimal. Have you got some constructive suggestions to improve the situation?
"The one who says something cannot be done should never interrupt the one who is doing it."
Strong words Posted May 25, 2012 18:30 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
the place that X is weakest is the place that Wayland is punting on. that's hardly the "don't interrupt the person doing it" situation.
Strong words Posted May 25, 2012 18:56 UTC (Fri) by renox (subscriber, #23785) [Link]
> Have you got some constructive suggestions to improve the situation?
Not really: the reason why X is not in a good state is due to chronic lack of manpower ( http://www.phoronix.com/scan.php?page=news_item&px=MT... )..
Wayland will "help" by doing less, OK, but let's not pretend that the existence of Wayland is a good thing..
But what's the better alternative to Wayland? Posted May 25, 2012 22:25 UTC (Fri) by sdalley (subscriber, #18550) [Link]
> let's not pretend that the existence of Wayland is a good thing..
There seems to be some memo that I didn't get. _Why_ is the existence of Wayland a _bad_ thing? What else would be better? It is a long overdue refactoring of the display/rendering/windowing plumbing that is careful not to reinvent new wheels but replace old and wobbly ones. In the medium term it will allow X to drop a load of old cruft.
This will surely end up making the overstretched X maintainers' lives easier, and more fulfilling than bodging improvements that are better and more simply done elsewhere.
It seems to be well supported by Red Hat and hopefully Canonical will soon be getting actively involved too.
As for remote-X issues, I certainly don't disagree there's problems there.
These problems, however, are not within Wayland's scope at present. Its design carefully leaves a clear field in which to fix them. And so long as workarounds like Xvnc and Xpra continue to work, we should at least not go backwards.
What's not to like? It seems to me that Wayland deserves our support and help during the inevitable teething issues rather than criticism.
You betray your ignorance of wayland Posted May 26, 2012 23:51 UTC (Sat) by butlerm (subscriber, #13312) [Link]
>This doesn't mean that remote rendering won't be possible with Wayland, it just means that you will have to put a remote rendering server on top of Wayland. One such server could be the X.org server, but other options include an RDP server, a VNC server or somebody could even invent their own new remote rendering model
This is where I get confused. Presumably, the use of direct-to-Wayland backends with toolkits like GTK and QT will normally make things worse (if not impossible) for remote operation. So are the advantages of Wayland with X layered on top substantial enough that it is a major improvement over the status quo? Or do the real advantages of Wayland only come when you eliminate the X layer in-between?
Furthermore, if Wayland does the compositing and the input arbitration, is it really necessary for X to run out of process in this case? Couldn't you just have libXCB or whatever have multiple backends, one a stub for remote operation using the X protocol, and the other an in-process rasterizer for use with Wayland, etc?
You betray your ignorance of wayland Posted May 27, 2012 10:25 UTC (Sun) by Jonno (subscriber, #49613) [Link]
With Wayland (the protocol) there are two possible ways to do remote operation:
Option 1: Remote rendering *on top of* Wayland. In this scenario clients (applications) don't do rendering themselves, but sends rendering commands to the display server, which render the windows and ask the Wayland compositor to display them. This will ofcourse require changes to the clients, or to the toolkit they use. You can use the standard compositor (e.g. Weston) on the display server, but will need a rendering server and protocol as well. One existing solution is to use xserver and X11, but developing a better protocol is a possible future improvement.
Option 2: Remote composition *below* Wayland. In this scenario clients render the windows themselves and ask the local compositor to display them. The local compositor, however, does not, but instead compress the windows and sends them over the network to the display server, which in turn asks its Wayland compositor to display them. This will work with all Wayland clients without modification. You can use the standard compositor (e.g. Weston) on the display server, but will need a proxy compositor and client to forward the windows over the network. This is not yet implemented in production-ready code (though there are abandoned proof-of-concept code for older Wayland versions), but is expected to be the default once done.
Option 2 is often called VNC-like because you send pre-rendered images over the network, but unlike actual VNC, you will get rootless windows that integrate just as well as remote X11 windows, so a better description would be Xpra-like. For most (but not all) applications option 2 will require more bandwidth than option 1, but option 2 will require less roundtrips and are thus not as sensitive to lag (a.k.a. poor ping times).
User of dial-up connections and users on over-saturated local networks might want to deploy option 1 (i.e. no change from today), but most use cases will be better served by option 2 (i.e. better performance than today).
You betray your ignorance of wayland Posted May 27, 2012 21:12 UTC (Sun) by raven667 (subscriber, #5198) [Link]
Option 2 is probably the better architecture, every client will get it for free and it is the technique that has the most research and work behind it. As far as I know the main protocols (ICA, RDP, PCoIP, SPICE, VNC) are all designed this way at the core and are all using similar optimization techniques and research to reduce bandwidth usage and reduce lag. What kind of rendering protocol is the OnLive service using?
You betray your ignorance of wayland Posted May 28, 2012 5:52 UTC (Mon) by butlerm (subscriber, #13312) [Link]
RDP is based on T.128, which has the usual set of rendering operations, font and image caching, and so on. I understand that ICA is similar, and so is SPICE. Of course actual implementations may rely more on bitmap updates then the supported rendering commands these days for relatively obvious reasons.
You betray your ignorance of wayland Posted May 28, 2012 6:43 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> RDP is based on T.128
I'm not sure if that's the chicken or the egg, these protocols (RDP, ICA) have been deployed for more than 20 years and I'm not sure that the standards you references aren't just ex post facto documentation of existing practice.
> the usual set of rendering operations, font and image caching, and so on
One more thing to point out is that all the protocols I listed are add-ons to an existing system (mostly MS Windows) that isn't designed around remoting applications and so has to integrate with an infrastructure designed around local display, the same kind of problems that would need to be solved to remote native Wayland applications.
The methods for local display and remote display have little relation to one another and I think experience has shown that this is a good arrangement, trying to do both with the same method leads to a design that is poor for both cases.
Does any of that sound similar to your understanding of the situation? 8-)
You betray your ignorance of wayland Posted May 28, 2012 6:33 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> Presumably, the use of direct-to-Wayland backends with toolkits like GTK and QT will normally make things worse (if not impossible) for remote operation.
The existing robust X backends aren't just going to evaporate, the toolkits are already multi-platform and Wayland is just an additional backend.
> So are the advantages of Wayland with X layered on top substantial enough that it is a major improvement over the status quo?
Yes, it takes the hardware handling out of X and leaves it with just the protocol to support existing apps. The hardware handling can be much better done outside of the X framework than within it. X can be much simpler and more robust if it isn't trying to handle the underlying hardware.
> Or do the real advantages of Wayland only come when you eliminate the X layer in-between?
There is probably sufficient advantage even if the only native Wayland client was the X server although in practice toolkits are going to have a direct Wayland option and eliminate the middleman for local display (only).
> Couldn't you just have libXCB or whatever have multiple backends, one a stub for remote operation using the X protocol, and the other an in-process rasterizer for use with Wayland, etc?
I may be talking above my knowledge level but my guess is that X apps and toolkits just aren't architected in a way where that makes any sense. The people who are designing and implementing Wayland are also the ones who designed and maintain X so my guess is that they are aware of the different architectural options and are picking the best ones.
You betray your ignorance of wayland Posted May 28, 2012 15:59 UTC (Mon) by butlerm (subscriber, #13312) [Link]
>The existing robust X backends aren't just going to evaporate, the toolkits are already multi-platform and Wayland is just an additional backend.
My question here is basically can the toolkit switch dynamically so that the same application binary be run in both X mode or Wayland mode, depending on the runtime environment?
If so, that would be outstanding, if not that could put a major impediment in the deployment of such applications until some form of remote operation is working. I can't see a server distribution standardizing on applications that can't be accessed remotely.
You betray your ignorance of wayland Posted May 28, 2012 16:19 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I thought the way this was being implemented in the toolkits was to check for environment variables to know which output to use.
You betray your ignorance of wayland Posted May 28, 2012 17:40 UTC (Mon) by Jonno (subscriber, #49613) [Link]
I don't know about GTK+, but Qt 4.8 and 5.0 autodetects backend at runtime, which can be overridden by a command line argument to the application (i.e. if you have both Wayland and X11 running).
NB: For Qt 4.8 you need to explicitly configure Qt with -qpa to get the new modular backends, the default is X11 only. In Qt 5.0 the hard-coded X11 port will be gone and replaced with a modular xcb backend.
You betray your ignorance of wayland Posted May 29, 2012 7:51 UTC (Tue) by butlerm (subscriber, #13312) [Link]
Thanks, that is excellent news. Perhaps a little more work than running everything through a generalized version of the XCB API, but accomplishing the same thing nonetheless, and probably more flexible too.
You betray your ignorance of wayland Posted May 29, 2012 21:53 UTC (Tue) by nix (subscriber, #2304) [Link]
Yeah. If Gtk does that too, most objections to Wayland basically fall away: nobody's likely to implement Wayland-only programs (just as people don't write against raw Xlib these days), and if the toolkits can switch based on an env var or something, the user can choose with whatever granularity is desired between insane blazing performance and remotability (which means I can turn remotability on and forget about Wayland completely).
You betray your ignorance of wayland Posted May 30, 2012 5:47 UTC (Wed) by aquasync (subscriber, #26654) [Link]
I would expect so, using the GDK_BACKEND environment variable (see the gtk broadway demos).
|
|||||||||||||