GSoC 2017 org applications open ( sourcing interest and ideas)
by Corey W Sheldon
As some of you may know, every year Google hosts the Google Summer of
Code (GSoC), last year we participated with some decent results for a
few projects. I was just sending this heads up to those whom may be
interested in partaking as a mentor or student (even if you are already
a fedora contributor) for a project within Fedora.
Basic requirements for students and ideas are below and find the full
lowdown at [0].
What are the eligibility requirements for participation?
* You must be at least 18 years of age
* You must currently be a full or part-time student (or have been
accepted for the fall term) at an accredited university as of the
student acceptance date
* You must be eligible to work in the country you will reside in during
the program
* You have not already been accepted as a Student in GSoC more than once
* You must reside in a country that is not currently embargoed by the
United States. See Program Rules for more information.
Prospective students: read the Student Manual [1]
Prospective Mentors: read the Mentors Manual [2]
[0] https://developers.google.com/open-source/gsoc/faq
[1]
https://developers.google.com/open-source/gsoc/resources/manual#student_m...
[2]
https://developers.google.com/open-source/gsoc/resources/manual#mentor_ma...
Hopefully I will see some of you among the applications.
--
Corey W Sheldon
M:703.839.6609:|:D:310.909.7672
PGP:|:0x4B1616F5BDFCC807:|:0x151D53B9C62FA404:|
|:0x418E43BCA33F2A72:|:|:0xA82F0594E76CB213:|:|:0x6B4FFDF3D89BCFA5:|
|:https://keybase.io/linuxmodder:|:https://ameridea.github.io:|
|:https://cs.danychtech.com
A goal is not always meant to be reached, it often serves simply as
something to aim at. --Bruce Lee
Absorb what is useful, discard what is not, add what is uniquely your
own. --Bruce Lee
Any man willing to sacrifice security for convenience, is deserving of
neither. -- Benjamin Franklin
Disclaimer: All correspondence shall be deemed of a sensitive nature,
and not re-distributed without good cause or per-approval.
All Emails shall be GPG signed or carry a attached vcf/asc blob, any
email lacking this shall be treated with healthy skepticism.
6 years, 10 months
Adding out-of-tree wifi drivers to the Fedora kernel pkg
by Hans de Goede
Hi All,
There are quite a few popular cheap x86 devices,
such as the first gen Intel Compute Stick and
many many ARM boards which have sdio wifi chips.
Unfortunately the mainline kernel lacks drivers
for almost all sdio wifi chips, so Fedora ends
up not supporting wifi on these devices, making
it unattractive to run Fedora on these devices.
I want to fix this and I've been thinking about
how to fix this. Options are:
a) A copr with kmod-s, this is not a good answer
for 3 reasons:
1) It is a pain to maintain as it needs rebuilds
each kernel build
2) It is not really a solution as copr does not
build for ARM
3) On most of these devices wifi is the only
network connectivity, so not having support
on the install media makes it very hard to
get wifi going to the point that an user will
likely just give up
b) A copr with dkms modules, this is not a good answer
for 2 reasons:
1) Building kernel modules from source on the users
system is ugly and more importantly fragile
2) On most of these devices wifi is the only
network connectivity, so not having support
on the install media makes it very hard to
get wifi going to the point that an user will
likely just give up
c) Integrate the driver into the Fedora kernel pkg,
which means that:
1) It will always be rebuild together with the kernel
2) It will be available at and directly after installation
d) Get the driver upstreamed. Unfortunately many of
these drivers are vendor code, which often is ported
windows code with lots of ugly glue; and the effort to
get this upstream will take more time then I have
to invest into this. Also if this were easy it would
have been done by now, there are quite a few people
interested in this. With this said I know that work
is being done on upstreaming esp8089 support and
the rtl8xxxu maintainer is looking on extending
that with sdio support solving the problem for
realtek chip. Note the ETA of any of this is unclear.
As such I've come to the conclusion that from a user
pov the only really good solution is c.
As such I would like to (for starters) add this driver:
https://github.com/hadess/rtl8723bs
Which is fully open source and although not ready for
upstream, actively maintained by the community, to the
driver/staging directory of the Fedora kernel pkg.
I realize this goes against the no out-of-tree kernel
modules in Fedora rule, but I believe it is time we
bend that rule a bit. IIRC that rule was made to
disallow so called kmod packages, which as I've listed
above indeed have a bunch of downsides. However I
believe that by simply integrating the driver into
the fedora kernel srpm we can avoid these issues.
I also believe that this rule goes against Fedora's
basic principles:
-It goes against the First principle, many other distros
are shipping with this driver
-It goes against the Features principle, disallowing
people to have working wifi is a mis-Feature
-It goes against the Freedom principle, if a contributor
is willing to spend time to maintain such a driver
he/she should have the freedom to do so
I realize that this rule was made to protect the Fedora
kernel maintainers from getting a lot of extra work on
their plate caused by such drivers. But note that I'm
not asking the Fedora kernel team to do any work on this,
I'm volunteering to do both the integration work as well
as maintaining these drivers going forward. If one a
rebase to the next -rc1 things break, feel free to simply
comment out the patch adding the driver(s) I will check
each rc1 what the state is (test the driver on hardware
with the specific sdio wifi chip) and fix any build or
runtime issues, this is something which I'm doing anyways
for my own kernel builds.
All I'm asking from the fedora kernel team is permission
to add the driver.
Regards,
Hans
6 years, 10 months
[PATCH] Support multitouch touchpads in Surface Type Cover
by Dennis Chen
This patch adds a set of patches that are either in linux-next or
headed to linux-next.
Since commit 8fe89ef076fa1 ("HID: multitouch: enable the Surface 3 Type
Cover to report multitouch data"), the Type Cover can be properly handled
by hid-multitouch and don't require any special quirk in the kernel.
These patches allow the Type Cover devices to report data with the
hid-multitouch driver and expires device support with hid-microsoft.
See here: https://lkml.org/lkml/2016/11/25/447
Signed-off-by: Dennis Chen <barracks510(a)gmail.com>
---
...uch-enable-Surface-3-Type-Cover-Pro-to-re.patch | 121 +++++++++++++++++++++
...uch-enable-Surface-4-Type-Cover-Pro-non-J.patch | 88 +++++++++++++++
...uch-enable-the-Surface-4-Type-Cover-Pro-J.patch | 83 ++++++++++++++
kernel.spec | 11 ++
4 files changed, 303 insertions(+)
create mode 100644 HID-multitouch-enable-Surface-3-Type-Cover-Pro-to-re.patch
create mode 100644 HID-multitouch-enable-Surface-4-Type-Cover-Pro-non-J.patch
create mode 100644 HID-multitouch-enable-the-Surface-4-Type-Cover-Pro-J.patch
diff --git a/HID-multitouch-enable-Surface-3-Type-Cover-Pro-to-re.patch b/HID-multitouch-enable-Surface-3-Type-Cover-Pro-to-re.patch
new file mode 100644
index 0000000..7915f59
--- /dev/null
+++ b/HID-multitouch-enable-Surface-3-Type-Cover-Pro-to-re.patch
@@ -0,0 +1,121 @@
+From c3aa437e0c6e8e84c92c99a5d4f6a20ecd3c1dcb Mon Sep 17 00:00:00 2001
+From: Dennis Chen <barracks510(a)gmail.com>
+Date: Thu, 19 Jan 2017 04:42:10 -0500
+Subject: [PATCH 3/3] HID: multitouch: enable Surface 3 Type Cover Pro to
+ report multitouch data
+
+Nearly identical to the previous set of patches related to Microsoft
+Surface Keyboards.
+
+Removes Surface Pro 3 generation TypeCover support from hid-microsoft
+so proper multitouch data can be reported from the touchpad.
+
+Signed-off-by: Dennis Chen <barracks510(a)gmail.com>
+---
+ drivers/hid/hid-core.c | 10 ++--------
+ drivers/hid/hid-ids.h | 3 ---
+ drivers/hid/hid-microsoft.c | 6 ------
+ drivers/hid/usbhid/hid-quirks.c | 7 ++-----
+ 4 files changed, 4 insertions(+), 22 deletions(-)
+
+diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
+index d173e7f..52863e7 100644
+--- a/drivers/hid/hid-core.c
++++ b/drivers/hid/hid-core.c
+@@ -724,10 +724,7 @@ static void hid_scan_collection(struct hid_parser *parser, unsigned type)
+ hid->group = HID_GROUP_SENSOR_HUB;
+
+ if (hid->vendor == USB_VENDOR_ID_MICROSOFT &&
+- (hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3 ||
+- hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2 ||
+- hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP ||
+- hid->product == USB_DEVICE_ID_MS_POWER_COVER) &&
++ hid->product == USB_DEVICE_ID_MS_POWER_COVER &&
+ hid->group == HID_GROUP_MULTITOUCH)
+ hid->group = HID_GROUP_GENERIC;
+
+@@ -1982,9 +1979,6 @@ static const struct hid_device_id hid_have_special_driver[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
+- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3) },
+- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2) },
+- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_DIGITAL_MEDIA_7K) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_DIGITAL_MEDIA_600) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_DIGITAL_MEDIA_3KV1) },
+@@ -2308,7 +2302,7 @@ __ATTRIBUTE_GROUPS(hid_dev);
+
+ static int hid_uevent(struct device *dev, struct kobj_uevent_env *env)
+ {
+- struct hid_device *hdev = to_hid_device(dev);
++ struct hid_device *hdev = to_hid_device(dev);
+
+ if (add_uevent_var(env, "HID_ID=%04X:%08X:%08X",
+ hdev->bus, hdev->vendor, hdev->product))
+diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
+index 87486ae..12f00a6 100644
+--- a/drivers/hid/hid-ids.h
++++ b/drivers/hid/hid-ids.h
+@@ -722,9 +722,6 @@
+ #define USB_DEVICE_ID_MS_SURFACE_PRO_2 0x0799
+ #define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
+ #define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
+-#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3 0x07dc
+-#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2 0x07e2
+-#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP 0x07dd
+ #define USB_DEVICE_ID_MS_POWER_COVER 0x07da
+
+ #define USB_VENDOR_ID_MOJO 0x8282
+diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
+index d856726..96e7d32 100644
+--- a/drivers/hid/hid-microsoft.c
++++ b/drivers/hid/hid-microsoft.c
+@@ -274,12 +274,6 @@ static const struct hid_device_id ms_devices[] = {
+ .driver_data = MS_NOGET },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
+ .driver_data = MS_DUPLICATE_USAGES },
+- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3),
+- .driver_data = MS_HIDINPUT },
+- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2),
+- .driver_data = MS_HIDINPUT },
+- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP),
+- .driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER),
+ .driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_COMFORT_KEYBOARD),
+diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
+index f6432c5..80df173 100644
+--- a/drivers/hid/usbhid/hid-quirks.c
++++ b/drivers/hid/usbhid/hid-quirks.c
+@@ -102,9 +102,6 @@ static const struct hid_blacklist {
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_SURFACE_PRO_2, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2, HID_QUIRK_NO_INIT_REPORTS },
+- { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3, HID_QUIRK_NO_INIT_REPORTS },
+- { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2, HID_QUIRK_NO_INIT_REPORTS },
+- { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750, HID_QUIRK_NO_INIT_REPORTS },
+@@ -293,7 +290,7 @@ static void usbhid_remove_all_dquirks(void)
+
+ }
+
+-/**
++/**
+ * usbhid_quirks_init: apply USB HID quirks specified at module load time
+ */
+ int usbhid_quirks_init(char **quirks_param)
+@@ -357,7 +354,7 @@ static const struct hid_blacklist *usbhid_exists_squirk(const u16 idVendor,
+
+ if (bl_entry != NULL)
+ dbg_hid("Found squirk 0x%x for USB HID vendor 0x%hx prod 0x%hx\n",
+- bl_entry->quirks, bl_entry->idVendor,
++ bl_entry->quirks, bl_entry->idVendor,
+ bl_entry->idProduct);
+ return bl_entry;
+ }
+--
+2.7.4
+
diff --git a/HID-multitouch-enable-Surface-4-Type-Cover-Pro-non-J.patch b/HID-multitouch-enable-Surface-4-Type-Cover-Pro-non-J.patch
new file mode 100644
index 0000000..84e1f39
--- /dev/null
+++ b/HID-multitouch-enable-Surface-4-Type-Cover-Pro-non-J.patch
@@ -0,0 +1,88 @@
+From 1db9191b1d5945269150e0687f85e81ccca6a3c1 Mon Sep 17 00:00:00 2001
+From: Daniel Keller <daniel.keller(a)gcd.de>
+Date: Tue, 10 Jan 2017 20:39:31 +0100
+Subject: [PATCH 2/3] HID: multitouch: enable Surface 4 Type Cover Pro (non-JP)
+ to report multitouch data
+
+Nearly identical to the patch "multitouch: enable the Surface 4 Type Cover Pro
+(JP) to report multitouch data"
+
+We can now remove the support of the Surface 4 Type Cover Pro (not JP versions)
+from hid-microsoft so it can properly report multi touch from the touchpad.
+
+Signed-off-by: Daniel Keller <daniel.keller(a)gcd.de>
+Acked-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
+Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
+---
+ drivers/hid/hid-core.c | 4 ----
+ drivers/hid/hid-ids.h | 2 --
+ drivers/hid/hid-microsoft.c | 4 ----
+ drivers/hid/usbhid/hid-quirks.c | 2 --
+ 4 files changed, 12 deletions(-)
+
+diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
+index 3c8af87..d173e7f 100644
+--- a/drivers/hid/hid-core.c
++++ b/drivers/hid/hid-core.c
+@@ -727,8 +727,6 @@ static void hid_scan_collection(struct hid_parser *parser, unsigned type)
+ (hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3 ||
+ hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2 ||
+ hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP ||
+- hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_4 ||
+- hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_2 ||
+ hid->product == USB_DEVICE_ID_MS_POWER_COVER) &&
+ hid->group == HID_GROUP_MULTITOUCH)
+ hid->group = HID_GROUP_GENERIC;
+@@ -1987,8 +1985,6 @@ static const struct hid_device_id hid_have_special_driver[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP) },
+- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4) },
+- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_DIGITAL_MEDIA_7K) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_DIGITAL_MEDIA_600) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_DIGITAL_MEDIA_3KV1) },
+diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
+index d816c54..87486ae 100644
+--- a/drivers/hid/hid-ids.h
++++ b/drivers/hid/hid-ids.h
+@@ -725,8 +725,6 @@
+ #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3 0x07dc
+ #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2 0x07e2
+ #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP 0x07dd
+-#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_4 0x07e4
+-#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_2 0x07e8
+ #define USB_DEVICE_ID_MS_POWER_COVER 0x07da
+
+ #define USB_VENDOR_ID_MOJO 0x8282
+diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
+index 2b706b5..d856726 100644
+--- a/drivers/hid/hid-microsoft.c
++++ b/drivers/hid/hid-microsoft.c
+@@ -280,10 +280,6 @@ static const struct hid_device_id ms_devices[] = {
+ .driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP),
+ .driver_data = MS_HIDINPUT },
+- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4),
+- .driver_data = MS_HIDINPUT },
+- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_2),
+- .driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER),
+ .driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_COMFORT_KEYBOARD),
+diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
+index 7eccbf8..f6432c5 100644
+--- a/drivers/hid/usbhid/hid-quirks.c
++++ b/drivers/hid/usbhid/hid-quirks.c
+@@ -105,8 +105,6 @@ static const struct hid_blacklist {
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP, HID_QUIRK_NO_INIT_REPORTS },
+- { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4, HID_QUIRK_NO_INIT_REPORTS },
+- { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_2, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750, HID_QUIRK_NO_INIT_REPORTS },
+--
+2.7.4
+
diff --git a/HID-multitouch-enable-the-Surface-4-Type-Cover-Pro-J.patch b/HID-multitouch-enable-the-Surface-4-Type-Cover-Pro-J.patch
new file mode 100644
index 0000000..9ae56d0
--- /dev/null
+++ b/HID-multitouch-enable-the-Surface-4-Type-Cover-Pro-J.patch
@@ -0,0 +1,83 @@
+From 929b0f22473cc45891dee2f58ef0a25fba6c5750 Mon Sep 17 00:00:00 2001
+From: Yuta Kobayashi <alu.ula(a)outlook.com>
+Date: Mon, 19 Dec 2016 02:36:45 +0000
+Subject: [PATCH 1/3] HID: multitouch: enable the Surface 4 Type Cover Pro (JP)
+ to report multitouch data
+
+Since commit 8fe89ef076fa1 ("HID: multitouch: enable the Surface 3 Type
+Cover to report multitouch data"), the TypeCover can be properly handled
+by hid-multitouch and don't require any special quirk in the kernel.
+
+Remove the support of the Surface 4 Type Cover Pro (JP) from
+hid-microsoft so it can properly report multitouch from the touchpad.
+
+Signed-off-by: Yuta Kobayashi <alu.ula(a)outlook.com>
+Reviewed-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
+Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
+---
+ drivers/hid/hid-core.c | 2 --
+ drivers/hid/hid-ids.h | 1 -
+ drivers/hid/hid-microsoft.c | 2 --
+ drivers/hid/usbhid/hid-quirks.c | 1 -
+ 4 files changed, 6 deletions(-)
+
+diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
+index ea36b55..3c8af87 100644
+--- a/drivers/hid/hid-core.c
++++ b/drivers/hid/hid-core.c
+@@ -729,7 +729,6 @@ static void hid_scan_collection(struct hid_parser *parser, unsigned type)
+ hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP ||
+ hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_4 ||
+ hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_2 ||
+- hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_JP ||
+ hid->product == USB_DEVICE_ID_MS_POWER_COVER) &&
+ hid->group == HID_GROUP_MULTITOUCH)
+ hid->group = HID_GROUP_GENERIC;
+@@ -1990,7 +1989,6 @@ static const struct hid_device_id hid_have_special_driver[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_2) },
+- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_JP) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_DIGITAL_MEDIA_7K) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_DIGITAL_MEDIA_600) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_DIGITAL_MEDIA_3KV1) },
+diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
+index f46f2c5..d816c54 100644
+--- a/drivers/hid/hid-ids.h
++++ b/drivers/hid/hid-ids.h
+@@ -727,7 +727,6 @@
+ #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP 0x07dd
+ #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_4 0x07e4
+ #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_2 0x07e8
+-#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_JP 0x07e9
+ #define USB_DEVICE_ID_MS_POWER_COVER 0x07da
+
+ #define USB_VENDOR_ID_MOJO 0x8282
+diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
+index 74b7b84..2b706b5 100644
+--- a/drivers/hid/hid-microsoft.c
++++ b/drivers/hid/hid-microsoft.c
+@@ -284,8 +284,6 @@ static const struct hid_device_id ms_devices[] = {
+ .driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_2),
+ .driver_data = MS_HIDINPUT },
+- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_JP),
+- .driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER),
+ .driver_data = MS_HIDINPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_COMFORT_KEYBOARD),
+diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
+index e9d6cc7..7eccbf8 100644
+--- a/drivers/hid/usbhid/hid-quirks.c
++++ b/drivers/hid/usbhid/hid-quirks.c
+@@ -107,7 +107,6 @@ static const struct hid_blacklist {
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_2, HID_QUIRK_NO_INIT_REPORTS },
+- { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_4_JP, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750, HID_QUIRK_NO_INIT_REPORTS },
+--
+2.7.4
+
diff --git a/kernel.spec b/kernel.spec
index 8d97cb7..f5ee0d9 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -584,6 +584,14 @@ Patch849: 0001-iio-Use-event-header-from-kernel-tree.patch
# Fix build issue with armada_trace
Patch851: Armada-trace-build-fix.patch
+# These following patches enable Surface Type Cover multitouch feedback.
+Patch900: HID-multitouch-enable-the-Surface-4-Type-Cover-Pro-J.patch
+
+Patch901: HID-multitouch-enable-Surface-4-Type-Cover-Pro-non-J.patch
+
+# https://patchwork.kernel.org/patch/9525369/
+Patch902: HID-multitouch-enable-Surface-3-Type-Cover-Pro-to-re.patch
+
# END OF PATCH DEFINITIONS
%endif
@@ -2154,6 +2162,9 @@ fi
#
#
%changelog
+* Thu Jan 19 2017 Dennis Chen <barracks510(a)gmail.com>
+- Provide multitouch capability to Surface Type Cover devices
+
* Wed Jan 18 2017 Justin M. Forbes <jforbes(a)fedoraproject.org> - 4.10.0-0.rc4.git2.1
- Linux v4.10-rc4-101-gfa19a76
--
2.7.4
6 years, 10 months
Re: Adding out-of-tree wifi drivers to the Fedora kernel pkg
by Hans de Goede
Hi,
On 18-01-17 15:16, Bastien Nocera wrote:
> On Tue, 2017-01-17 at 14:05 +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 17-01-17 13:44, Bastien Nocera wrote:
>>> On Tue, 2017-01-17 at 13:11 +0100, Hans de Goede wrote:
>>>> Hi All,
>>>>
>>>> There are quite a few popular cheap x86 devices,
>>>> such as the first gen Intel Compute Stick and
>>>> many many ARM boards which have sdio wifi chips.
>>>>
>>>> Unfortunately the mainline kernel lacks drivers
>>>> for almost all sdio wifi chips, so Fedora ends
>>>> up not supporting wifi on these devices, making
>>>> it unattractive to run Fedora on these devices.
>>>>
>>>> I want to fix this and I've been thinking about
>>>> how to fix this. Options are:
>>>>
>>>> a) A copr with kmod-s, this is not a good answer
>>>> for 3 reasons:
>>>> 1) It is a pain to maintain as it needs rebuilds
>>>> each kernel build
>>>> 2) It is not really a solution as copr does not
>>>> build for ARM
>>>> 3) On most of these devices wifi is the only
>>>> network connectivity, so not having support
>>>> on the install media makes it very hard to
>>>> get wifi going to the point that an user will
>>>> likely just give up
>>>>
>>>> b) A copr with dkms modules, this is not a good answer
>>>> for 2 reasons:
>>>> 1) Building kernel modules from source on the users
>>>> system is ugly and more importantly fragile
>>>> 2) On most of these devices wifi is the only
>>>> network connectivity, so not having support
>>>> on the install media makes it very hard to
>>>> get wifi going to the point that an user will
>>>> likely just give up
>>>>
>>>> c) Integrate the driver into the Fedora kernel pkg,
>>>> which means that:
>>>> 1) It will always be rebuild together with the kernel
>>>> 2) It will be available at and directly after installation
>>>>
>>>> d) Get the driver upstreamed. Unfortunately many of
>>>> these drivers are vendor code, which often is ported
>>>> windows code with lots of ugly glue; and the effort to
>>>> get this upstream will take more time then I have
>>>> to invest into this. Also if this were easy it would
>>>> have been done by now, there are quite a few people
>>>> interested in this. With this said I know that work
>>>> is being done on upstreaming esp8089 support and
>>>> the rtl8xxxu maintainer is looking on extending
>>>> that with sdio support solving the problem for
>>>> realtek chip. Note the ETA of any of this is unclear.
>>>>
>>>> As such I've come to the conclusion that from a user
>>>> pov the only really good solution is c.
>>>>
>>>> As such I would like to (for starters) add this driver:
>>>> https://github.com/hadess/rtl8723bs
>>>>
>>>> Which is fully open source and although not ready for
>>>> upstream, actively maintained by the community, to the
>>>> driver/staging directory of the Fedora kernel pkg.
>>>>
>>>> I realize this goes against the no out-of-tree kernel
>>>> modules in Fedora rule, but I believe it is time we
>>>> bend that rule a bit. IIRC that rule was made to
>>>> disallow so called kmod packages, which as I've listed
>>>> above indeed have a bunch of downsides. However I
>>>> believe that by simply integrating the driver into
>>>> the fedora kernel srpm we can avoid these issues.
>>>>
>>>> I also believe that this rule goes against Fedora's
>>>> basic principles:
>>>>
>>>> -It goes against the First principle, many other distros
>>>> are shipping with this driver
>>>> -It goes against the Features principle, disallowing
>>>> people to have working wifi is a mis-Feature
>>>> -It goes against the Freedom principle, if a contributor
>>>> is willing to spend time to maintain such a driver
>>>> he/she should have the freedom to do so
>>>>
>>>> I realize that this rule was made to protect the Fedora
>>>> kernel maintainers from getting a lot of extra work on
>>>> their plate caused by such drivers. But note that I'm
>>>> not asking the Fedora kernel team to do any work on this,
>>>> I'm volunteering to do both the integration work as well
>>>> as maintaining these drivers going forward. If one a
>>>> rebase to the next -rc1 things break, feel free to simply
>>>> comment out the patch adding the driver(s) I will check
>>>> each rc1 what the state is (test the driver on hardware
>>>> with the specific sdio wifi chip) and fix any build or
>>>> runtime issues, this is something which I'm doing anyways
>>>> for my own kernel builds.
>>>>
>>>> All I'm asking from the fedora kernel team is permission
>>>> to add the driver.
>>>
>>> Would it be that much more work to get those drivers in staging?
>>
>> Getting them in staging requires some commitment to them
>> becoming mainline ready in due course. AFAICT no one is
>> working on fixing the remaining blockers for e.g. the
>> rtl8723bs code and the rtl8xxxu path is likely a better
>> way forward.
>
> I don't think that's true. Larry Finger has maintained a number of
> "vendor" drivers in staging, obsoleting them when a better option, most
> notably Jes' reverse-engineered/reimplemented driver for a number of
> Realtek devices.
>
> At least for rtl8723bs, I'd be happy to try and get it in the kernel,
Ok, if you want to take a shot at this I'm all for it. Let me know
if I can do anything to help (IMHO it would be better for you to
start the discussion on this upstream since you're currently
somewhat maintaining the out of tree version).
On a related topic besides the kernel-driver we also need to get
the firmware into linux-firmware. I expect we will be able to do
this as linux-firmware already has a whole bunch of realtek firmwares
but we still need to do this. Do you know who we need to contact
for this ? Note I'm willing to go and work on the firmware side of
this.
> as long as we don't spend too much time trying to follow the kernel's
> indentation policy, which would just make rebasing more complicated.
>
> There are also a number of vendors which might be interested in this,
> like NextThingCo for their CHIP (CHIP Pro too?), and Endless for one of
> their ARM machines.
Right, this is exactly why I believe that it is important to have
sdio wifi work out of the box on Fedora.
Regards,
Hans
6 years, 10 months
[PATCH] Enable perf jvmti plugin
by Jiri Olsa
hi,
attached patch makes the jvmti perf plugin being packaged
under perf package, tested with rpm build:
$ rpm -qpl /home/jolsa/rpmbuild/RPMS/x86_64/perf-4.10.0-0.rc3.git3.1.fc25.x86_64.rpm | grep jvm
/usr/lib64/libperf-jvmti.so
Laura,
it needs your patch first to be included in fedora kernel sources:
cd7f355ac406 perf jvmti: Create libdir directory before installing libperf-jvmti.so
so far it's in Ingo's tree, I guess it'll soon hit the linus tree.
jirka
---
Enabling the build of the jvmti perf plugin and install it under:
/usr/lib64/libperf-jvmti.so
Signed-off-by: Jiri Olsa <jolsa(a)kernel.org>
---
kernel.spec | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel.spec b/kernel.spec
index 938b776cde3b..b7c9f8c4486e 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -382,6 +382,7 @@ BuildRequires: sparse
%if %{with_perf}
BuildRequires: zlib-devel binutils-devel newt-devel python-devel perl(ExtUtils::Embed) bison flex xz-devel
BuildRequires: audit-libs-devel
+BuildRequires: java-devel
%ifnarch s390 s390x %{arm}
BuildRequires: numactl-devel
%endif
@@ -1649,7 +1650,7 @@ BuildKernel %make_target %kernel_image
%endif
%global perf_make \
- make -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" %{?cross_opts} -C tools/perf V=1 NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 NO_JVMTI=1 prefix=%{_prefix}
+ make -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" %{?cross_opts} -C tools/perf V=1 NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 prefix=%{_prefix}
%if %{with_perf}
# perf
# make sure check-headers.sh is executable
@@ -2014,6 +2015,7 @@ fi
%files -n perf
%defattr(-,root,root)
%{_bindir}/perf
+%{_libdir}/libperf-jvmti.so
%dir %{_libdir}/traceevent/plugins
%{_libdir}/traceevent/plugins/*
%dir %{_libexecdir}/perf-core
--
2.9.3
6 years, 10 months
Re: Adding out-of-tree wifi drivers to the Fedora kernel pkg
by Hans de Goede
Hi,
On 17-01-17 13:44, Bastien Nocera wrote:
> On Tue, 2017-01-17 at 13:11 +0100, Hans de Goede wrote:
>> Hi All,
>>
>> There are quite a few popular cheap x86 devices,
>> such as the first gen Intel Compute Stick and
>> many many ARM boards which have sdio wifi chips.
>>
>> Unfortunately the mainline kernel lacks drivers
>> for almost all sdio wifi chips, so Fedora ends
>> up not supporting wifi on these devices, making
>> it unattractive to run Fedora on these devices.
>>
>> I want to fix this and I've been thinking about
>> how to fix this. Options are:
>>
>> a) A copr with kmod-s, this is not a good answer
>> for 3 reasons:
>> 1) It is a pain to maintain as it needs rebuilds
>> each kernel build
>> 2) It is not really a solution as copr does not
>> build for ARM
>> 3) On most of these devices wifi is the only
>> network connectivity, so not having support
>> on the install media makes it very hard to
>> get wifi going to the point that an user will
>> likely just give up
>>
>> b) A copr with dkms modules, this is not a good answer
>> for 2 reasons:
>> 1) Building kernel modules from source on the users
>> system is ugly and more importantly fragile
>> 2) On most of these devices wifi is the only
>> network connectivity, so not having support
>> on the install media makes it very hard to
>> get wifi going to the point that an user will
>> likely just give up
>>
>> c) Integrate the driver into the Fedora kernel pkg,
>> which means that:
>> 1) It will always be rebuild together with the kernel
>> 2) It will be available at and directly after installation
>>
>> d) Get the driver upstreamed. Unfortunately many of
>> these drivers are vendor code, which often is ported
>> windows code with lots of ugly glue; and the effort to
>> get this upstream will take more time then I have
>> to invest into this. Also if this were easy it would
>> have been done by now, there are quite a few people
>> interested in this. With this said I know that work
>> is being done on upstreaming esp8089 support and
>> the rtl8xxxu maintainer is looking on extending
>> that with sdio support solving the problem for
>> realtek chip. Note the ETA of any of this is unclear.
>>
>> As such I've come to the conclusion that from a user
>> pov the only really good solution is c.
>>
>> As such I would like to (for starters) add this driver:
>> https://github.com/hadess/rtl8723bs
>>
>> Which is fully open source and although not ready for
>> upstream, actively maintained by the community, to the
>> driver/staging directory of the Fedora kernel pkg.
>>
>> I realize this goes against the no out-of-tree kernel
>> modules in Fedora rule, but I believe it is time we
>> bend that rule a bit. IIRC that rule was made to
>> disallow so called kmod packages, which as I've listed
>> above indeed have a bunch of downsides. However I
>> believe that by simply integrating the driver into
>> the fedora kernel srpm we can avoid these issues.
>>
>> I also believe that this rule goes against Fedora's
>> basic principles:
>>
>> -It goes against the First principle, many other distros
>> are shipping with this driver
>> -It goes against the Features principle, disallowing
>> people to have working wifi is a mis-Feature
>> -It goes against the Freedom principle, if a contributor
>> is willing to spend time to maintain such a driver
>> he/she should have the freedom to do so
>>
>> I realize that this rule was made to protect the Fedora
>> kernel maintainers from getting a lot of extra work on
>> their plate caused by such drivers. But note that I'm
>> not asking the Fedora kernel team to do any work on this,
>> I'm volunteering to do both the integration work as well
>> as maintaining these drivers going forward. If one a
>> rebase to the next -rc1 things break, feel free to simply
>> comment out the patch adding the driver(s) I will check
>> each rc1 what the state is (test the driver on hardware
>> with the specific sdio wifi chip) and fix any build or
>> runtime issues, this is something which I'm doing anyways
>> for my own kernel builds.
>>
>> All I'm asking from the fedora kernel team is permission
>> to add the driver.
>
> Would it be that much more work to get those drivers in staging?
Getting them in staging requires some commitment to them
becoming mainline ready in due course. AFAICT no one is
working on fixing the remaining blockers for e.g. the
rtl8723bs code and the rtl8xxxu path is likely a better
way forward.
> The main problem I see with adding those drivers is that we still had
> to have patches on top of other subsystems to get them working in 4.x
> kernels. Would we still need those?
No, the baytrail sdio problems have been fixed. There are
still some other baytrail issues, but those happen without
sdio wifi to so they are likely unrelated.
> If the only reason why we cannot land this in staging is because of
> indentation rules, I'd rather we made sure those rules are relaxed,
> rather than reindenting everything and making it harder to rebase.
As said I believe that to get these in staging we need to
provide upstream with a path forward, which I believe for
this specific case is adding sdio support to the rtl8xxxu
driver. Which means that there is no incentive for upstream
to take the rtl8723bs code into staging, as it will likely
be replaced by something else rather then ever get promoted
to non-staging.
Also there are a bunch of other sdio wifi drivers used on
ARM (mostly more realtek models) which will require significant
work before being ready for staging then the rtl8723bs code,
all of which will be wasted work since ultimately we plan
to go the rtl8xxxu route.
Regards,
Hans
6 years, 10 months
Kernel 4.9 rebase plans
by Laura Abbott
Hi,
Kernel 4.9 was officially released yesterday, December 11. This kernel is
being built for rawhide today. The plan for bringing this kernel into
F24/F25 is going to follow roughly the same schedule as in the past.
This means pushing the new rebase when we think it's stable enough.
In the past, this has happened around the .2 stable release (so 4.9.2
in this case). Given the holidays, this won't be happening until 2017
but we'll be monitoring closely. I'll update with more information
once it gets closer. As always, please let us know if you have any
questions.
Thanks,
Laura
6 years, 11 months
