Response from Synaptics regarding Linux drivers

Written by

Here is the mail I received this afternoon from Synaptics regarding the petition:

The open source Linux kernel currently has a PS2 touchpad driver from the third party open source community which was not developed, reviewed, or tested by Synaptics. Based on industry and customer pull, we do not support PS2 interfaces for Linux as it is not a strategic fit for our roadmap or support model. In general, the trend in the PC industry is HID/I2C, for which we do offer driver support. Our intent is to submit our HID/I2C driver to Kernel.org as time, resource allocation and customer project prioritization allow.
Best Regards,
Nick

———–

Here is what I sent in response:

It would be great if you were to get working on submitting a driver to the kernel. People will help you find bugs in the code as part of this process, and improve it in ways you hadn’t considered. It occurred to me over Thanksgiving after your last email that writing a Linux driver but not freely releasing is like cooking that big meal and not eating it. Proprietary software was one of the big mistakes of the baby boomer generation.

I will pass this information along to the petitioners with some questions / comments. When you make something public, I hope you make a public announcement as well because it will be read more than your average one. People care about companies that share their values. Here is a video of Steam’s recent announcements regarding Linux that I thought you might appreciate: http://www.youtube.com/watch?v=g8PMUvuHK4g

Unfortunately, I’m not knowledgeable about the benefit of supporting the PS2 interface vs HID/I2C. However, I can say that not every trend in the industry is a good one. IPv6 is a trend that still hasn’t arrived. I think UEFI as implemented is of dubious benefit. Can you please explain in more detail why HID/I2C is better? I may do some more research on this topic and ask other people, but I can say that the existing venerable standard has gotten us a long way including multi-touch and gestures. So I wouldn’t recommend supporting only the new trends which are sometimes fads. The Linux kernel supports 60 file systems. Can you consider to support the extremely popular as well as the latest?

When you think about getting code into the kernel, I want to emphasize making good default configuration values. You didn’t mention that aspect so I raise it again in hopes of a response. I’m sure your driver will have interesting knobs people will want to tweak, but you are the best people to know what they should be by default for your devices. So can you please commit to providing a great out of the box experience by including tested and tuned configuration data along with code?

2. Getting 10,000 lines of code into the kernel could take a year. For example, it took quite some time for Google’s wakelocks code to make it upstream. In that case, there were big disagreements about the design which may or may not apply to your code, but unforeseen things like that do happen. Also, your lawyers end up taking time and I’m sure your kernel developers are already busy and possibly understaffed. As this is your first big contribution it will take even longer.

So in addition to the question of whether supporting only one standard is good enough, there is a question of timeframe. That is why I created the #2 item. I realize you didn’t write or review any of the existing code. However, because you hadn’t released any code publicly in the past other people have written it for your customers. The kernel is filled with code written by other people but this module has your name on it and is depended on by millions of people.

Here is the key point. By fixing that code, you will help many customers today. A 10 line fix to a driver would quickly be accepted and deployed to millions within a few weeks and the entire community within 6 months. It would possibly be backported to older releases as as your hardware is so popular and important.

I read a line that a good way to judge an airline is by what happens *after* they lose your luggage. If they were to tell you that yes, they’ve lost your luggage, but they are implementing a new baggage tracking system that will give it to you in a year, you might not be so happy with that answer.

I believe if you were to ask your Linux customers whether they would want you to fix 20-30 bugs in the existing already-upstreamed code or work on some big chunk of new code whose date for delivery is very uncertain, they would want you to fix the existing code first. So this strategy is faster for us and cheaper for you and could even be a useful learning process on the way to the HID/I2C utopia. Once all your customers are no longer frustrated you can run the process for your new driver at your leisure. So can you re-consider your priorities in light of the situation that currently exists?

3. Also, you didn’t mention the #3 issue about providing a UI to configure your devices. Can you please think holistically about the end-user experience and realize that as your hardware gets more sophisticated, a UI to configure the device becomes more necesssary? You could provide a good value for palm detection by default, but a UI allows me to test and change it if the default did not work for my situation. It is quite difficult to tweak a knob without a UI.

In this code as well, people will help you here, by for example suggesting gestures to be added or turned off by default. By not working on freely-available configuration code, you are missing feedback loops everyone will benefit from. It is overall easier to write UI code on Linux versus Windows. There are more Environments / toolkits, but only 3 are used by 90% of users, and the code will be debugged for you, compiled, deployed and translated for you, etc. You don’t need to start from scratch as these environments have code, but it just needs to be improved. Can you please reconsider this end-to-end aspect as well? It is also easier to find people qualified to write UI code versus drivers and I think most people would judge this to be more important than a HID/I2C driver.

Thanks again for your mail. I hope you will consider these issues and respond soon. It is great to hear of a new path, but I can recommend you verify it is what your customers actually want as opposed to what some people say they ought to want. I will post a request for feedback on your ideas, but these are my initial thoughts.

——

Please post your thoughts about this, preferably on the petition page.

Comments

11 responses to “Response from Synaptics regarding Linux drivers”

December 13, 2013
Matthias
Thanks for your campaign and all your work Keith 🙂
I agree with your mail and personally I think that they need to talk/explain to the kernel people why they don’t want to support PS/2 and why HID/I2C seems to be a better option.
I know that real supporting Open Source development is a challenge for a traditional business company, where you can also get problems (patents, community shitstorms, loosing control, …). But as you write, it can be also a very good experience and give your products not only better Linux support, but also finding new supporters that help you to create better software.
Reply
December 14, 2013
johannes
thanks for your petition and the initiative. I just signed up. just a advice from my personal expirience: things work faster and smoother without personal judgments and too much criticism. people tend to take it too personal and don’t get motivated to cooperate. best, johannes
Reply
1. December 14, 2013
  KeithCu
  Good advice 😉 I’ll keep it in mind. My primary concern is to explain as best I can what I think is in their best interest and ours. I imagine many companies as full of bureaucrats from the movie Brazil. Perhaps that causes me to not care what they think about me.
  Reply
December 14, 2013
Dick
Thanks for your good work and the answer to Synaptics.
Reply
December 14, 2013
Jack
It’s great to hear that Synaptics is intending to get its drivers included in the Kernel. In your response to them, you pointed out that getting their code accepted into the Kernel could take some time. As an interim solution (which you could, given that you are in contact with Synaptics, put to them as an idea) could be to make their driver available (either as open or closed source – what matters is getting the trackpads working ASAP) to end users to install.
Reply
1. December 15, 2013
  KeithCu
  That is another idea, and I’ll think about mentioning it, but given that no one as seen the code, I’m not sure how well it will even work. Then what? Look at the nVidia / AMD drivers, even today! It might need months of bug-fixing and it is better off doing that process in public where it can happen faster. This petition is about free software, so asking for proprietary software seems like a loss and a distraction. But I’ll keep it in mind, depending on what happens next.
  Reply
2. December 16, 2013
  Kevin Krammer
  Regarding drivers available as closed source, they claim to already do that. At least this is how I interpret this part of their response: In general, the trend in the PC industry is HID/I2C, for which we do offer driver support.
  Emphasised by Our intent is to submit our HID/I2C driver to Kernel.org…
  Reply
December 14, 2013
CFWhitman
The difference between PS/2 and HID/I2C is mostly a hardware one. If your mouse and/or keyboard attaches to your computer through those little round PS/2 connectors, then they are PS/2 devices. If they attach through a USB port, then they are HID (Human Interface Device) protocol devices. I2C devices are generally not found on the outside of computers, but they are also relieant on HID protocols. Internally a device may be using any of these methods even if they don’t use the same type of connectors as devices attached to the outside of your computer. Synaptics probably isn’t producing any new PS/2 devices (a lot of their old touchpads are PS/2 devices). The existing open source Linux driver for PS/2 touchpads is pretty good, and they probably feel that releasing anything in addition to it for PS/2 devices is a waste of their time. The devices that are problematic are not PS/2 devices, so if they really are going to address issues with I2C devices (or if they make any USB based ones), that should be a good thing.
Incidentally UEFI is not so bad. It’s only Secure Boot that is a problem. Coreboot is great, of course, but UEFI without Secure Boot, like the computer I’m typing this from, really is a more flexible technology than the old BIOS.
Reply
1. December 16, 2013
  wat
  Your comment seems to ignore the fact that HID is just a protocol for describing communications with human interface devices, and the actual serial protocol chatted with over the universal serial bus can still be anything. In this case, the Linux kernel is talking to the Synaptics hardware with the ancient PS/2 protocol, and it works (only just) because of PS/2 emulation in the Synaptics hardware.
  The Synaptics devs are talking about writing a whole new driver to speak whichever flavor of I2C their devices happen to use.
  Reply
January 15, 2014
Aaron Hamilton
The bus doesn’t really matter, as long as the hardware supports it.
PS/2 I believe has some issues for them, not the least of which is that they support it through emulation on the hardware side, and I’m sure they’d love to remove that extra complexity some time soon(maybe within the next couple release cycles, since they seem rather eager to submit their HID-based implementations).
This would lead to a simpler, cheaper, more-reliable product, potentially with that silicon area used for something else(intel’s integrated graphics started as something to put in underallocated die area that had been freed up).
Reply
February 10, 2014
Yagnesh
Great job Keith! I really appreciate your interest and initiative.
Reply