Summary: | Patch for Trust KB-1400S | ||
---|---|---|---|
Product: | xkeyboard-config | Reporter: | Anselmo Luginbuhl <anselmo> |
Component: | General | Assignee: | xkb |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | enhancement | ||
Priority: | medium | Keywords: | NEEDINFO |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
patch to add Trust KB-1400S
just an indentation correction on the previous patch More appropriate inet file, to be applied after the other two patch. |
Description
Anselmo Luginbuhl
2009-03-06 11:04:17 UTC
Created attachment 23596 [details] [review] just an indentation correction on the previous patch I made a little indentation error in the previous patch in the inet file, this one correct some lines indentation. A couple of questions: 1. Would it be fair just to call it trust_slimline? 2. I guess, just including media_nav_acpi_common would be enough, wouldn't it? Could you please try? Do not be afraid of mappings for non-existing keys. (In reply to comment #2) > A couple of questions: > 1. Would it be fair just to call it trust_slimline? > 2. I guess, just including media_nav_acpi_common would be enough, wouldn't it? > Could you please try? Do not be afraid of mappings for non-existing keys. > Hi, 1. That was my first thought, but today there are three Slimline keyboard, KB-1400S, KB-1350D, KB-1450 series, all with different media keys. May be more in the future? So i've choosed a more articulated name, but that's my first time with xkb, so feel free to change it. 2. You're perfectly right, media_nav_acpi_common cover nearly all the keys. The only one that as to be differently mapped is the home key. I've added in attachement the patch to inet, but as i'm not very used to git, the patch is the diff after my two previous patch, so, if you prefer, i should "restart" from the beginning. Created attachment 23601 [details] [review] More appropriate inet file, to be applied after the other two patch. Actually I'd prefer to have I32 as WWW rather than HomePage, as a consistent usage pattern across symbols/inet file. I guess the difference is not critical here - usually tools can be configured to use either in shortcuts. Is that essential key for you? (In reply to comment #5) > Actually I'd prefer to have I32 as WWW rather than HomePage, as a consistent > usage pattern across symbols/inet file. I guess the difference is not critical > here - usually tools can be configured to use either in shortcuts. > > Is that essential key for you? > Absolutly not, it was just to be coherent with the symbol printed on the keyboard (a little home), and consequentially with default shortcut configuration and keyboard symbol. And as i've seen on inet, I32 is used for different keys so I thouthgt it was right to change it. Well, If you do "grep I32 inet", you'll see that it is never HomePage - it is either WWW or something totally different. I spent some time cleaning it :) So, if you're happy just to use media_nav_acpi_common, I'll do the following thing. No modification to symbols/inet. Instead, the rule will be added to rules/base.m_s.part: trust_slimline = inet(media_nav_acpi_common) That way your model should work fine. Agreed? Absolutely, I just wanted to add my keyboard and give some contribution, and I don't know the complete schema of xkb. So your decision is final from my point of view. You've been very diplomatic with me :-), so I really appreciate your consideration of my little work. You're very welcome. I depend on contributors like you (since I cannot buy all keyboard models myself:), so I am just trying not to irritate people. Thanks for your contribution, the code will be put in place ASAP. Committed! You can check in git - or wait till next release in May. Thanks again for the contribution. I'll probably wait longer as i'm using debian testing :-( Thank's for your work. Anselmo |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.