Bug 1645070

For starters, try running "dmesg -w" from a terminal and then press the non working keys and see if any messages appear.

If that does not result in any messages, do:

sudo dnf install evemu

And then "sudo dnf evemu-record" select device 0, press the non working keys and if there is any output copy and paste the output (including the device name of device 0) here. Then repeat for device 1 again if you see any output note it here, then repeat for device 2, etc. until you are out of devices.

Created attachment 1500564 [details]
evemu-record for input9, input10 and input11

Thanks you for the procedure.

There is no messages displayed with dmesg -w when doing the shortcuts.

Here the list of available input

Available devices:
/dev/input/event0:	Sleep Button
/dev/input/event1:	Power Button
/dev/input/event2:	Lid Switch
/dev/input/event3:	Power Button
/dev/input/event4:	AT Translated Set 2 keyboard
/dev/input/event5:	USB Optical Mouse
/dev/input/event6:	Video Bus
/dev/input/event7:	Video Bus
/dev/input/event8:	ITE Tech. Inc. ITE Device(8910)
/dev/input/event9:	ITE Tech. Inc. ITE Device(8910) Keyboard
/dev/input/event10:	ITE Tech. Inc. ITE Device(8910)
/dev/input/event11:	ITE Tech. Inc. ITE Device(8910) Consumer Control
/dev/input/event12:	ITE Tech. Inc. ITE Device(8910) Wireless Radio Control
/dev/input/event13:	ITE Tech. Inc. ITE Device(8910) System Control
/dev/input/event14:	Asus Wireless Radio Control
/dev/input/event15:	Asus WMI hotkeys
/dev/input/event16:	USB2.0 HD UVC WebCam: USB2.0 HD
/dev/input/event17:	ELAN1200:00 04F3:303E Touchpad
/dev/input/event18:	HDA Intel PCH Headphone
/dev/input/event19:	HDA Intel PCH HDMI/DP,pcm=3
/dev/input/event20:	HDA Intel PCH HDMI/DP,pcm=7
/dev/input/event21:	HDA Intel PCH HDMI/DP,pcm=8
/dev/input/event22:	HDA Intel PCH HDMI/DP,pcm=9
/dev/input/event23:	HDA Intel PCH HDMI/DP,pcm=10

The devices that seems to react to the « fn » shortcuts are these ones :

/dev/input/event9:	ITE Tech. Inc. ITE Device(8910) Keyboard
/dev/input/event10:	ITE Tech. Inc. ITE Device(8910)
/dev/input/event11:	ITE Tech. Inc. ITE Device(8910) Consumer Control

After testing all inputs :

The event9 triggers all keyboard keys and only one « fn » shortcut : fn + F9
The event10 triggers all « fn » shorcuts except the fn + F9 and the fn + F[1-3]
The event11 triggers the mute / volume down / volume up « fn » shortcuts fn + F[1-3].

I've missed one « fn » shortcut :

fn + numpad enter (calculator icon) :

E: 0.000001 0003 0028 0000	# EV_ABS / ABS_MISC             0
E: 0.000001 0003 0028 0001	# EV_ABS / ABS_MISC             1
E: 0.000001 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +0ms
E: 0.051993 0003 0028 0000	# EV_ABS / ABS_MISC             0
E: 0.051993 0003 0028 0001	# EV_ABS / ABS_MISC             1
E: 0.051993 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +51ms

Do you need a photo of the real keyboard layout ?

(In reply to vivien.frasca from comment #3)

Thank you for the provided input, this should be enough for me to figure out a fix, but I've been a bit buried in other work, so I've not yet had time to look further into this.

> Do you need a photo of the real keyboard layout ?

AFAICS I do not need a photo to fix this.

I'll get back to you when I have some time to look into this.

Sorry for being a bit slow to get around to this.

So the behavior for Fn + F1 - F3 as well as Fn + F9 is normal.

To fix the other Fn + F# and Fn + arrow up/down keys I'm going to need some more info.

Can you (directly after a new boot do):

dmesg > dmesg.txt

And attach the generated dmesg.txt here please?

Also please provide the output of the "lsusb" command.

I'm also going to need a couple of other files.

First of all become root:

sudo su -

Then do:

ls /sys/kernel/debug/hid

I expect there to be a couple of directories there starting with "0003:048d"
for all directories starting with this, please do:

cat /sys/kernel/debug/hid/0003\:048d\:.../rdesc > rdesc-003\:048d\:...

And then attach all the rdesc-003\:048d\:... files here.

Created attachment 1508225 [details]
dmesg and lsusb output

Hello Hans.

There's no problem about time issue, it's been a while my laptop does not run very well (about the touchpad especially).

Please find attached the dmesg right after a reboot and a lsusb output.

Created attachment 1508229 [details]
rdesc of 3 hid devices

About hid debug, I don't have the one starting with 0003:048d

I've got 3 devices : 

0003:0B05:1869.0002
0003:1BCF:0005.0001
0018:04F3:303E.0003

So please find attached the content of the three rdesc files.

Created attachment 1508230 [details]
real keyboard layout

Please also find attached the picture of the physical keyboard.

If you need full description of each Fn shortcuts, let me know and I'll give you that.

Thanks, I think I've written a patch which should at least fix some of the Fn keys.

I've started a test kernel-build for this which is currently building here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=31064206

This should be done in aprox. a couple of hours.

Once the build is finished, please install it and give it a test, test-instructions for kernel builds directly from koji are here:
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Please use evemu-record to test again, I expect at least some of the Fn keys which were not working before to work now.

If there are Fn keys which still do not work, then please run "dmesg -w" from a terminal and while it is running press the non functioning Fn + F# combo. This should result in a message like this one in the dmesg output:

Unmapped Asus vendor usagepage code 0x##

Please note down the value of the 0x## printed for each non working Fn + F# combo (and note down which value belongs to which key).  Then I should be able to also fix the remaining non working keys.

========

Somewhat related to this, Linux should also be able to control the brightness of your keyboard backlight and the hid-asus driver (which I'm modifying to support your Fn keys) has support for controlling this.

But on most models, this is best done through other means, chances are this already works on your laptop. Can you do "ls /sys/class/leds" and if there is a device there which looks like it is your keyboard backlight do:

cat /sys/class/leds/foo/max_brightness

(replacing foo with the name of the device on your system) and then as root try doing:

echo ## > /sys/class/leds/foo/brightness

Where ## is a number in the range of 0 to max_brightness, e.g. if the cat on max_brightness returns 31, try:

echo 0 > /sys/class/leds/foo/brightness
echo 15 > /sys/class/leds/foo/brightness
echo 31 > /sys/class/leds/foo/brightness

And see if that gives you kbd backlight off, half bright, full bright.

If you do not get a device for your kbd brightness under /sys/class/leds/ then I can provide another test-kernel which tries to enable this functionality through the hid-asus driver.

Hello Hans,

I've tried your kernel (with the nvidia akmod manually built) and only 3 Fn shortcuts don't works. 

Here the dmesg output :

Fn + F4 (microphone mute)

[  360.811981] asus 0003:0B05:1869.0002: Unmapped Asus vendor usagepage code 0x00
[  360.811983] asus 0003:0B05:1869.0002: Unmapped Asus vendor usagepage code 0x7c
[  360.875970] asus 0003:0B05:1869.0002: Unmapped Asus vendor usagepage code 0x7c
[  360.875971] asus 0003:0B05:1869.0002: Unmapped Asus vendor usagepage code 0x00

Fn + F5 (fan speed)

[  422.291971] asus 0003:0B05:1869.0002: Unmapped Asus vendor usagepage code 0x00
[  422.291973] asus 0003:0B05:1869.0002: Unmapped Asus vendor usagepage code 0x99
[  422.351968] asus 0003:0B05:1869.0002: Unmapped Asus vendor usagepage code 0x99
[  422.351970] asus 0003:0B05:1869.0002: Unmapped Asus vendor usagepage code 0x00

Fn + F9 (switch screen)

// Nothing is triggered / shown

Every other shortcuts work fine !

Below the list of registered device leds (ls /sys/class/leds/)

asus-wireless::airplane -> ../../devices/LNXSYSTM:00/LNXSYBUS:00/ATK4002:00/leds/asus-wireless::airplane
input16::capslock -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/input/input16/input16::capslock
input16::compose -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/input/input16/input16::compose
input16::kana -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/input/input16/input16::kana
input16::numlock -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/input/input16/input16::numlock
input16::scrolllock -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/input/input16/input16::scrolllock
input4::capslock -> ../../devices/platform/i8042/serio0/input/input4/input4::capslock
input4::numlock -> ../../devices/platform/i8042/serio0/input/input4/input4::numlock
input4::scrolllock -> ../../devices/platform/i8042/serio0/input/input4/input4::scrolllock
phy0-led -> ../../devices/pci0000:00/0000:00:1c.6/0000:04:00.0/leds/phy0-led

I've done these instructions but without any changes :

echo 0 > /sys/class/leds/phy0-led/brightness

To ensure that this works fine I've done the same on the airplane led and it worked correctly

echo 1 > /sys/class/leds/asus-wireless::airplane/brightness

the airplane has been turned on

echo 0 > /sys/class/leds/asus-wireless::airplane/brightness

the airplane has been turned off

I've also tried all devices leds without any impact on the keyboard backlight.

(In reply to vivien.frasca from comment #10)
> Hello Hans,
> 
> I've tried your kernel (with the nvidia akmod manually built) and only 3 Fn
> shortcuts don't works. 

That is good news, thank you for testing.
 
> Here the dmesg output :
> 
> Fn + F4 (microphone mute)

<snip>

> Fn + F5 (fan speed)

<snip>

Ok, I've added mappging for both of these.

> [  422.291971] asus 0003:0B05:1869.0002: Unmapped Asus vendor usagepage code
> 0x00
> [  422.291973] asus 0003:0B05:1869.0002: Unmapped Asus vendor usagepage code
> 0x99
> [  422.351968] asus 0003:0B05:1869.0002: Unmapped Asus vendor usagepage code
> 0x99
> [  422.351970] asus 0003:0B05:1869.0002: Unmapped Asus vendor usagepage code
> 0x00
> 
> Fn + F9 (switch screen)
> 
> // Nothing is triggered / shown


As you've already seen with your earlier evemu-record debugging this hotjey sends an Alt + p keypress, this is normal. Windows interprets this as a "projector" hotkey. I guess we should probably add processing for this key-combo somewhere to GNOME3. In the mean time you can bind it (not sure to what) using the usual configmechanism for hotkeys in your desktop-environment.

> Below the list of registered device leds (ls /sys/class/leds/)
> 
> asus-wireless::airplane ->
> ../../devices/LNXSYSTM:00/LNXSYBUS:00/ATK4002:00/leds/asus-wireless::airplane
> input16::capslock ->
> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/
> input/input16/input16::capslock
> input16::compose ->
> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/
> input/input16/input16::compose
> input16::kana ->
> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/
> input/input16/input16::kana
> input16::numlock ->
> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/
> input/input16/input16::numlock
> input16::scrolllock ->
> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/
> input/input16/input16::scrolllock
> input4::capslock ->
> ../../devices/platform/i8042/serio0/input/input4/input4::capslock
> input4::numlock ->
> ../../devices/platform/i8042/serio0/input/input4/input4::numlock
> input4::scrolllock ->
> ../../devices/platform/i8042/serio0/input/input4/input4::scrolllock
> phy0-led -> ../../devices/pci0000:00/0000:00:1c.6/0000:04:00.0/leds/phy0-led
> 
> I've done these instructions but without any changes :

AH I guess I was not clear, you only needed to do this if something clearly was for the keyboard, e.g. had "kbd" or "keyboard" in the name. Clearly that is not the case. So nothing else is providing access to control the keybd backlight, which means that we should try to enable this in asus-hid driver.

I've started a new kernel test build adding bindings for the 2 keys which did not work so far and enabling kbd backlight support in the hid-asus driver for the USB-id if your laptop-keyb:

https://koji.fedoraproject.org/koji/taskinfo?taskID=31102912

Once it is done building please give this version a try. The 2 keys which did not work should work now (the Fan key will send a PROG4 event for lack of anything else matching) and hopefully you will also get an interface for the keyb backlight under /sys/class/backlights now.

I've tested the version 4.19.4-300.hdg2.fc29.x86_64

So there is no messages in dmesg -w when pressing Fn + F4 and Fn + F5

The Fn + F4 does not mute the microphone (I can see that in sound properties of Gnome 3, and there is no HUD icon like the volume up / down)

For the keyboard backlight, it works with the manual echoing of value in /sys/class/leds/asus::kbd_backlight/brightness

max_brightness is 3. Value from 3 to 0 reduces the keyboard leds brightness (0 turns them off).

Please also note that the Fn + DownArrow and Fn + UpArrow displays the HUD icon with the keyboard led icon

About the keyboard led management, I've seen that under Windows 10, the leds are dimming progressively to 0 when not using the keyboard nor the mouse after a small delay (10 seconds or something like that). Do you know if this behavior will be implemented ?

Please note that under /sys/class/backlight I've got only one device (already present with the hdg1 kernel) :

intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight

This is the laptop screen, there is only the new entry in /sys/class/leds.

Hi,

(In reply to vivien.frasca from comment #12)
> I've tested the version 4.19.4-300.hdg2.fc29.x86_64
> 
> So there is no messages in dmesg -w when pressing Fn + F4 and Fn + F5
> 
> The Fn + F4 does not mute the microphone (I can see that in sound properties
> of Gnome 3, and there is no HUD icon like the volume up / down)

A more interesting question is if it sends a KEY_MICMUTE event, and if FN+F5 send a KEY_PROG4 event, can you check this with evemu-record?

For GNOME not responding to the KEY_MICMUTE event, please file a bug here:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues

> For the keyboard backlight, it works with the manual echoing of value in
> /sys/class/leds/asus::kbd_backlight/brightness
> 
> max_brightness is 3. Value from 3 to 0 reduces the keyboard leds brightness
> (0 turns them off).

Good.
 
> Please also note that the Fn + DownArrow and Fn + UpArrow displays the HUD
> icon with the keyboard led icon

And changes the kbd-brightness down/up I assume ?

> About the keyboard led management, I've seen that under Windows 10, the leds
> are dimming progressively to 0 when not using the keyboard nor the mouse
> after a small delay (10 seconds or something like that). Do you know if this
> behavior will be implemented ?

This likely is a hardware feature controlled by the driver. Currently asus-hid does not have support for this, so this would require reverse-engineering the keyb-backlight protocol further to figure out how to enable this.

Note I'm not entirely sure if the kbd-backlight fade-out on inactivity is a hardware feature, there is a bug-report from an other Asus user asking to implement a software version here:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/93

> A more interesting question is if it sends a KEY_MICMUTE event, and if FN+F5 send a KEY_PROG4 event, can you check this with evemu-record?

Yes, these shortcuts triggers KEY_MICMUTE and KEY_PROG4.

> And changes the kbd-brightness down/up I assume ?

Unfortunately no, the icon is shown but the keyboard leds don't change. The leds fades in/out only by echoing the value in /sys/class/leds/asus::kbd_backlight/brightness

About the fade out it seems that it would be easier to implement this on software side.

(In reply to vivien.frasca from comment #16)
> > A more interesting question is if it sends a KEY_MICMUTE event, and if FN+F5 send a KEY_PROG4 event, can you check this with evemu-record?
> 
> Yes, these shortcuts triggers KEY_MICMUTE and KEY_PROG4.

Great, so that means that the kernel side of this is fixed. I've submitted the patches for this upstream now.

> > And changes the kbd-brightness down/up I assume ?
> 
> Unfortunately no, the icon is shown but the keyboard leds don't change. The
> leds fades in/out only by echoing the value in
> /sys/class/leds/asus::kbd_backlight/brightness

Hmm, that would be another gnome-settings-daemon bug, since we now both generate key-presses (which it sees, hence the OSD icon) and offering it a backlight interface, so it should take care of this. Can you go to power settings in gnome-control-center, you should see both a screen brightness and a keyboard brightness slider there, please check if the keyboard brightness slider is: a) present and b) works. After that file a bug for this agains g-s-d here:

https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues

And in the details include, that we've working keypresses and a working backlight interface under /sys/class/leds and also the results from a. and b. above.

> About the fade out it seems that it would be easier to implement this on
> software side.

Ack.

Created attachment 1508568 [details]
screenshot of gnome-settings-center

I don't have any dedicated slider for the keyboard in power section of gsc. I've checked all gsc UIs without finding any slider about the keyboard leds.

(In reply to vivien.frasca from comment #18)
> Created attachment 1508568 [details]
> screenshot of gnome-settings-center
> 
> I don't have any dedicated slider for the keyboard in power section of gsc.
> I've checked all gsc UIs without finding any slider about the keyboard leds.

Hmm, I was thinking that this could point to an upower bug and wanted to ask you for the output of: "upower -e" on your laptop. But testing it on my own laptop with kbd-backlight I did not see the kbd-backlight there either.

This is a bug in upower 0.99.8, upower 0.99.9 is in the Fedora updates repository now, please run as root "dnf update upower" and then reboot. After this you should see a "Keyboard brightness" slider in gnome-control-center's power settings and hopefully the hotkeys will then start to work too.

Perfect ! with the updated upower, the Fn + UpArrow and Fn + DownArrow are fading in/out the keyboard leds.

I now have a slider in power settings.

Everything works perfectly !

Can you keep me in touch about the version of official fedora's kernel that will apply your patches ? (in order to close this issue)

Thank you very much for this fix !

(In reply to vivien.frasca from comment #20)
> Can you keep me in touch about the version of official fedora's kernel that
> will apply your patches ? (in order to close this issue)

The patches have been accepted upstream and I've added them as a downstream patch to the Fedora kernels for now.

The updates system will post a message in this bug when the first kernel with the patches included gets pushed to the updates repo.

kernel-tools-4.19.7-200.fc28 kernel-headers-4.19.7-200.fc28 kernel-4.19.7-200.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a0914af224

kernel-tools-4.19.7-300.fc29 kernel-headers-4.19.7-300.fc29 kernel-4.19.7-300.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-5904d0794d

kernel-4.19.7-300.fc29, kernel-headers-4.19.7-300.fc29, kernel-tools-4.19.7-300.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-5904d0794d

kernel-4.19.7-200.fc28, kernel-headers-4.19.7-200.fc28, kernel-tools-4.19.7-200.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-a0914af224

Hello Hans.

I've tested the kernel 4.19.7-300.fc29.x86_64, the keyboard brightness shortcut behaves like described in comment https://bugzilla.redhat.com/show_bug.cgi?id=1645070#c16 and I don't have the keyboard sysclass...

ls -la /sys/class/leds/

total 0
drwxr-xr-x  2 root root 0 11 déc.  11:34 .
drwxr-xr-x 69 root root 0 11 déc.  11:28 ..
lrwxrwxrwx  1 root root 0 11 déc.  11:28 asus-wireless::airplane -> ../../devices/LNXSYSTM:00/LNXSYBUS:00/ATK4002:00/leds/asus-wireless::airplane
lrwxrwxrwx  1 root root 0 11 déc.  11:28 input16::capslock -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/input/input16/input16::capslock
lrwxrwxrwx  1 root root 0 11 déc.  11:28 input16::compose -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/input/input16/input16::compose
lrwxrwxrwx  1 root root 0 11 déc.  11:28 input16::kana -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/input/input16/input16::kana
lrwxrwxrwx  1 root root 0 11 déc.  11:28 input16::numlock -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/input/input16/input16::numlock
lrwxrwxrwx  1 root root 0 11 déc.  11:28 input16::scrolllock -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1869.0002/input/input16/input16::scrolllock
lrwxrwxrwx  1 root root 0 11 déc.  11:28 input4::capslock -> ../../devices/platform/i8042/serio0/input/input4/input4::capslock
lrwxrwxrwx  1 root root 0 11 déc.  11:28 input4::numlock -> ../../devices/platform/i8042/serio0/input/input4/input4::numlock
lrwxrwxrwx  1 root root 0 11 déc.  11:28 input4::scrolllock -> ../../devices/platform/i8042/serio0/input/input4/input4::scrolllock
lrwxrwxrwx  1 root root 0 11 déc.  11:28 phy0-led -> ../../devices/pci0000:00/0000:00:1c.6/0000:04:00.0/leds/phy0-led

There's no slider in gnome power settings.

Ugh this is my bad, I accidentally added an older version of the patch to the Fedora kernels. I've added the right version now and this should be picked up by the next kernel build.

A Fedora update associated with this bug has been pushed to the stable repository.

The problems still occurs with kernel 4.19.8-300.fc29.x86_64

Does your new patch is applied for this kernel ?

It'll be in 4.19.9-300.fc29.x86_64. I'll put this back into NEW and the update system/Randy Barlow will comment on the issue when the update is available in Bodhi.

kernel-4.19.9-200.fc28 kernel-headers-4.19.9-200.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-ea5710d5f4

kernel-4.19.9-300.fc29 kernel-headers-4.19.9-300.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2645eb8dab

A Fedora update associated with this bug has been pushed to the stable repository.

kernel-4.19.9-200.fc28, kernel-headers-4.19.9-200.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-ea5710d5f4

kernel-4.19.10-200.fc28, kernel-headers-4.19.10-200.fc28, kernel-tools-4.19.10-200.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-6e8c330d50

kernel-4.19.9-300.fc29, kernel-headers-4.19.9-300.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

kernel-4.19.10-200.fc28, kernel-headers-4.19.10-200.fc28, kernel-tools-4.19.10-200.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.