[SOLVED] LibreOffice and CUPS
Excerpts from Sergey Manucharian's message from Sat 14-May-16 12:27: > After recent system update (I'm on FreeBSD 11.0-CURRENT r298793) > LibreOffice doesn't see CUPS printers. It shows only "Generic printer", > but doesn't actually print anything. > I've found and posted the solution: https://forums.freebsd.org/threads/57815 Sergey. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing
On Sat, Oct 08, 2016 at 02:18:54AM +0300, Andriy Voskoboinyk wrote: > > Mon, 03 Oct 2016 03:55:23 +0300 було написано Kevin Lo : > > Hi! Hi Andriy, > Can you refresh the tree and retest it (dev.rtwn.0.debug=0x829f) ? I refreshed the tree and retested it, unfortunately it's still the same. Here's the log: https://people.freebsd.org/~kevlo/rtl8188ce-debuglog > > P.S. If Rx is still broken (status is always 0) try to execute > 'ifconfig wlan0 promisc' It doesn't help either :( > > On Sun, Oct 02, 2016 at 10:15:49AM -0700, Adrian Chadd wrote: > >> > >> hi, > > > > Hi Adrian, > > > >> can you turn on debugging? Do you see RX frames? > > > > No Rx frames. The log is pretty much the same one I sent on the list: > > https://lists.freebsd.org/pipermail/freebsd-wireless/2016-September/007093.html > > > >> -a > > > > Thanks, > > Kevin > > > >> On 1 October 2016 at 08:09, Kevin Lo wrote: > >> > Strange, rtwn(4) stops working. I tried to scan for the available > >> network, > >> > but it just returns empty results. > >> > > >> > On Fri, Sep 23, 2016 at 02:44:13PM +0300, Andriy Voskoboinyk wrote: > >> >> > >> >> Fri, 23 Sep 2016 10:18:30 +0300 було написано Kevin Lo > >> : > >> >> > >> >> Few more questions: > >> >> 1) does it work with h/w encryption support? (enabled by default) > >> >> (if 'yes' - I will remove 'hardware crypto enabled' warning). > >> >> 2) is there rate control support? (wlandebug -i wlan0 rate ; then > >> transmit > >> >> something - if it works then AMRR will print it's current status > >> >> periodically) > >> >> 3) can you test some disabled capabilities? (ad-hoc/AP modes, 11n) > >> >> (see r92ce_adj_devcaps() in > >> sys/dev/rtwn/rtl8192c/pci/r92ce_attach.c). > >> >> > >> >> > It works for me, thanks :) > >> >> > > >> >> > Kevin > >> >> > > >> >> > On Fri, Sep 23, 2016 at 09:08:15AM +0300, Andriy Voskoboinyk wrote: > >> >> >> > >> >> >> Fri, 23 Sep 2016 04:58:40 +0300 було написано Kevin Lo > >> >> >> : > >> >> >> > >> >> >> Thanks for the log file, > >> >> >> > >> >> >> Tx 'device timeouts' should be fixed in > >> >> >> > >> https://github.com/s3erios/rtwn/commit/f78d51b6ed8590e3aeb65fbf616aa767034a89f5 > >> >> >> (currently I'm reviewing PCI-specific code to see if there are any > >> >> >> additional > >> >> >> issues - e.g., there are no Rx events in the log file). > >> >> >> > >> >> >> > On Thu, Sep 22, 2016 at 01:54:21PM +0300, Andriy Voskoboinyk > >> wrote: > >> >> >> >> > >> >> >> >> Thu, 22 Sep 2016 12:24:42 +0300 було написано Kevin Lo > >> >> >> >> : > >> >> >> >> > >> >> >> >> Hi, > >> >> >> >> > >> >> >> >> So, the driver was fully tested. Thanks! > >> >> >> >> Can you set dev.rtwn.0.debug=0x829f for RTL8188CE to see how > >> big > >> >> >> >> the problem is? > >> >> >> > > >> >> >> > Sure. Here you go > >> >> >> https://people.freebsd.org/~kevlo/rtl8188ce-debug.txt > >> >> >> > > >> >> >> > Thanks, > >> >> >> > Kevin > >> >> >> > > >> >> >> >> > Hi Andriy, > >> >> >> >> > > >> >> >> >> > First of all, THANK YOU! You're doing amazing work! > >> >> >> >> > Second, I've done some testing on the following devices, > >> >> >> downloading > >> >> >> >> > FreeBSD-12.0-CURRENT-amd64-20160809-r303880-disc1.iso from > >> >> >> >> > ftp.freebsd.org: > >> >> >> >> > > >> >> >> >> > - ASUS USB-N10 NANO (RTL8188CUS): > >> >> >> >> > rtwn0: >> 2.00/2.00, > >> >> >> addr > >> >> >> >> > 3> on usbus0 > >> >> >> >> > rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > >> >> >> >> > > >> >> >> >> > - TP-Link TL-WN725N v2 (RTL8188EU): > >> >> >> >> > rtwn0: >> addr 4> on > >> >> >> >> > usbus0 > >> >> >> >> > rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R > >> >> >> >> > > >> >> >> >> > - D-Link DWA-131 (RTL8192CU): > >> >> >> >> > rtwn0: >> 2.00/2.00, > >> >> >> addr > >> >> >> >> > 3> on usbus0 > >> >> >> >> > rtwn0: MAC/BB RTL8192CU, RF 6052 2T2R > >> >> >> >> > > >> >> >> >> > - TP-Link Archer T4U (RTL8812AU): > >> >> >> >> > rtwn0: >> addr 7> on > >> >> >> >> > usbus0 > >> >> >> >> > rtwn0: MAC/BB RTL8812AU, RF 6052 2T2R > >> >> >> >> > > >> >> >> >> > - D-Link DWA-171 rev A1 (RTL8821AU): > >> >> >> >> > rtwn0: <802.11n WLAN Adapter> on usbus0 > >> >> >> >> > rtwn0: MAC/BB RTL8821AU, RF 6052 1T1R > >> >> >> >> > > >> >> >> >> > - RTL8188CE mini pcie: > >> >> >> >> > rtwn0: port 0xd000-0xd0ff mem > >> >> >> >> > 0x9080-0x90803fff irq 17 at device 0.0 on pci1 > >> >> >> >> > rtwn0: r92ce_attach: warning: hardware crypto enabled > >> >> >> >> > rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R > >> >> >> >> > > >> >> >> >> > All seems to be ok, except RTL8188CE PCIe adapter doesn't > >> work: > >> >> >> >> > > >> >> >> >> > rtwn0: r92ce_post_init: warning: net80211 ratectl is used > >> >> >> >> > rtwn0: device timeout > >> >> >> >> > > >> >> >> >> > Kevin > >> >> >> >> > > >> >> >> >> > On Mon, Sep 19, 2016 at 04:26:38PM +0300, Andriy Voskoboinyk > >> wrote: > >> >> >> >> >> > >> >> >> >> >> Thu, 01 Sep 2016 19:29:03 +0300 було написано Andriy > >> Vos
Re: [request for testing] isl, cyapa on chromebooks
On 10/10/2016 21:45, Michael Gmelin wrote: > I see three tasks here: - Andriy finishes his change, moving things from > smbus to iicbus, adding some workaround to keep the user experience like it > is - Someone else implements the device table mechanism for auto detection - > Someone else ports HDI over I2C to allow implementing drivers for devices > like the elan touchpad Matthias is referring to > > Makes sense? It does to me. Also, I can suggest another task related to SMBus / I2C. Looking at the code in the Linux chromeos_laptop driver I see that on some models some sensors are actually attached to SMBus rather that to I2C. And, for example, cyapa can be attached to either bus. But there is a quirk. cyapa won't work over a standard SMBus, it needs some extensions that are typically provided by Intel chipsets. I specifically mean the so called "I2C Block Read" and the transaction that results from the Block Write command when the I2C bit is set in the SMBus controller's configuration register. Neither of these modes is supported by our ichsmb(4) driver. But on Linux they are both supported and exposed as I2C_SMBUS_I2C_BLOCK_DATA transaction type. For one reference please see Mobile 4th Generation Intel® CoreTM Processor Family I/O Datasheet, section 5.21.1.1. And, just in case, ig4(4) is about the controllers described in section 5.22 of that document. Perhaps, I2C_SMBUS_I2C_BLOCK_DATA served as an inspiration (and perhaps a source of confusion) for Matt when he added smbus_trans(). Right now I do not have any good suggestion on how to expose that 90% SMBus, 10% I2C functionality in the FreeBSD model. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [request for testing] isl, cyapa on chromebooks
> On 10 Oct 2016, at 20:27, Matthias Apitz wrote: > >> El día Monday, October 10, 2016 a las 09:26:26AM -0600, Warner Losh escribió: >> >> I see no reason not to start the table right away based on >> smbios.sys.product and other criteria. I don't think we need all the >> matches that Linux uses, but we can expand the table if we find it so. >> Why have a stop gap that's a table that we kludge together when the >> real table is of comparable difficulty and wouldn't need to be >> reworked. > > Please let us together concentrate on getting other i2c devices working, > like the Elan TouchPad, because I fear that newer Chromebooks are all > equipped with this and not with the Cyapa anymore. > I see three tasks here: - Andriy finishes his change, moving things from smbus to iicbus, adding some workaround to keep the user experience like it is - Someone else implements the device table mechanism for auto detection - Someone else ports HDI over I2C to allow implementing drivers for devices like the elan touchpad Matthias is referring to Makes sense? -m ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [request for testing] isl, cyapa on chromebooks
El día Monday, October 10, 2016 a las 09:26:26AM -0600, Warner Losh escribió: > I see no reason not to start the table right away based on > smbios.sys.product and other criteria. I don't think we need all the > matches that Linux uses, but we can expand the table if we find it so. > Why have a stop gap that's a table that we kludge together when the > real table is of comparable difficulty and wouldn't need to be > reworked. Please let us together concentrate on getting other i2c devices working, like the Elan TouchPad, because I fear that newer Chromebooks are all equipped with this and not with the Cyapa anymore. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 Einheitsfeier? Nein, danke! Kann ich bitte mein Land wiederhaben und am 7. Oktober feiern. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [request for testing] isl, cyapa on chromebooks
On 10/10/2016 18:26, Warner Losh wrote: > I see no reason not to start the table right away based on > smbios.sys.product and other criteria. I don't think we need all the > matches that Linux uses, but we can expand the table if we find it so. > Why have a stop gap that's a table that we kludge together when the > real table is of comparable difficulty and wouldn't need to be > reworked. One simple reason for me personally. I do not have the hardware and I am not particularly interested in it. I am interested only in cleaning up the smbus interface and moving ig4iic to iicbus. I want to get done with that as quickly as possible and my goal is just that the result is not worse than the current code. I am sure that people who are more interested than me can make the code much better. > On Mon, Oct 10, 2016 at 5:46 AM, Michael Gmelin wrote: >> On Mon, 10 Oct 2016 14:35:22 +0300 >> Andriy Gapon wrote: >> >>> On 09/10/2016 23:22, Warner Losh wrote: There seems to be enough information present in the smbios data to know what devices are at what addresses. Perhaps we should use it as much as possible in well controlled situations to move this knowledge into the OS. >>> >>> So, I was thinking about maybe doing something like this to preserve >>> the status quo, to avoid requiring manual hints and to lay a >>> foundation for the proper Chromebook I2C slave discovery: >>> [snip] -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [request for testing] isl, cyapa on chromebooks
I see no reason not to start the table right away based on
smbios.sys.product and other criteria. I don't think we need all the
matches that Linux uses, but we can expand the table if we find it so.
Why have a stop gap that's a table that we kludge together when the
real table is of comparable difficulty and wouldn't need to be
reworked.
Warner
On Mon, Oct 10, 2016 at 5:46 AM, Michael Gmelin wrote:
> On Mon, 10 Oct 2016 14:35:22 +0300
> Andriy Gapon wrote:
>
>> On 09/10/2016 23:22, Warner Losh wrote:
>> > There seems to be enough information present in the smbios data to
>> > know what devices are at what addresses. Perhaps we should use it as
>> > much as possible in well controlled situations to move this
>> > knowledge into the OS.
>>
>> So, I was thinking about maybe doing something like this to preserve
>> the status quo, to avoid requiring manual hints and to lay a
>> foundation for the proper Chromebook I2C slave discovery:
>>
>>
>> static struct {
>> uint32_tctlrid,
>> const char *name;
>> uint_t addr;
>> } slaves[] = {
>> { 0x9c628086, "isl", 0x88 },
>> { 0x9c628086, "cyapa",0xce },
>> }
>>
>> static void
>> chromebook_i2c_identify(driver_t *driver, device_t bus)
>> {
>> device_t controller;
>> device_t child;
>> int i;
>>
>> /*
>>* A stop gap approach to preserve the status quo.
>>* A more intelligent approach is required to correctly
>>* identify a machine model and hadrdware available on it.
>>* For instance, DMI could be used.
>>* See
>> http://lxr.free-electrons.com/source/drivers/platform/chrome/chromeos_laptop.c
>>*/
>> controller = device_get_parent(bus);
>> if (strcmp(device_get_name(controller), "ig4iic") != 0)
>> return;
>>
>> for (i = 0; i < nitems(slaves); i++) {
>> if (device_find_child(bus, slave->name, -1) != NULL)
>> continue;
>> if (slave->ctlrid != pci_get_devid(controller))
>> continue;
>> child = BUS_ADD_CHILD(bus, 0, slave->name, -1);
>> if (child != NULL)
>> iicbus_set_addr(child, slave->addr);
>> }
>> }
>>
>> static device_method_t chromebook_i2c_methods[] = {
>> DEVMETHOD(device_identify, chromebook_i2c_identify),
>> { 0, 0 }
>> };
>>
>> static driver_t chromebook_i2c_driver = {
>> "chromebook_i2c",
>> chromebook_i2c_methods,
>> 0 /* no softc */
>> };
>>
>> static devclass_t chromebook_i2c_devclass;
>>
>> DRIVER_MODULE(chromebook_i2c, iicbus, chromebook_i2c_driver,
>> chromebook_i2c_devclass, 0, 0);
>> MODULE_DEPEND(chromebook_i2c, iicbus, IICBUS_MINVER, IICBUS_PREFVER,
>> IICBUS_MAXVER);
>> MODULE_VERSION(chromebook_i2c, 1);
>>
>> The idea is that this is a driver that listens for new iicbus-es and
>> adds isl and cyapa devices to a bus if some criteria are met.
>>
>
> For the Acer c720, these criteria would be:
>
> smbios.bios.vendor=="coreboot"
> smbios.system.maker=="Acer"
> smbios.system.product=="Peppy"
>
> See also
>
> boot/i386/libi386/biosmem.c
> dev/atkbdc/atkbdc.c
>
> - Michael
>
> --
> Michael Gmelin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [request for testing] isl, cyapa on chromebooks
On Mon, 10 Oct 2016 14:35:22 +0300
Andriy Gapon wrote:
> On 09/10/2016 23:22, Warner Losh wrote:
> > There seems to be enough information present in the smbios data to
> > know what devices are at what addresses. Perhaps we should use it as
> > much as possible in well controlled situations to move this
> > knowledge into the OS.
>
> So, I was thinking about maybe doing something like this to preserve
> the status quo, to avoid requiring manual hints and to lay a
> foundation for the proper Chromebook I2C slave discovery:
>
>
> static struct {
> uint32_tctlrid,
> const char *name;
> uint_t addr;
> } slaves[] = {
> { 0x9c628086, "isl", 0x88 },
> { 0x9c628086, "cyapa",0xce },
> }
>
> static void
> chromebook_i2c_identify(driver_t *driver, device_t bus)
> {
> device_t controller;
> device_t child;
> int i;
>
> /*
>* A stop gap approach to preserve the status quo.
>* A more intelligent approach is required to correctly
>* identify a machine model and hadrdware available on it.
>* For instance, DMI could be used.
>* See
> http://lxr.free-electrons.com/source/drivers/platform/chrome/chromeos_laptop.c
>*/
> controller = device_get_parent(bus);
> if (strcmp(device_get_name(controller), "ig4iic") != 0)
> return;
>
> for (i = 0; i < nitems(slaves); i++) {
> if (device_find_child(bus, slave->name, -1) != NULL)
> continue;
> if (slave->ctlrid != pci_get_devid(controller))
> continue;
> child = BUS_ADD_CHILD(bus, 0, slave->name, -1);
> if (child != NULL)
> iicbus_set_addr(child, slave->addr);
> }
> }
>
> static device_method_t chromebook_i2c_methods[] = {
> DEVMETHOD(device_identify, chromebook_i2c_identify),
> { 0, 0 }
> };
>
> static driver_t chromebook_i2c_driver = {
> "chromebook_i2c",
> chromebook_i2c_methods,
> 0 /* no softc */
> };
>
> static devclass_t chromebook_i2c_devclass;
>
> DRIVER_MODULE(chromebook_i2c, iicbus, chromebook_i2c_driver,
> chromebook_i2c_devclass, 0, 0);
> MODULE_DEPEND(chromebook_i2c, iicbus, IICBUS_MINVER, IICBUS_PREFVER,
> IICBUS_MAXVER);
> MODULE_VERSION(chromebook_i2c, 1);
>
> The idea is that this is a driver that listens for new iicbus-es and
> adds isl and cyapa devices to a bus if some criteria are met.
>
For the Acer c720, these criteria would be:
smbios.bios.vendor=="coreboot"
smbios.system.maker=="Acer"
smbios.system.product=="Peppy"
See also
boot/i386/libi386/biosmem.c
dev/atkbdc/atkbdc.c
- Michael
--
Michael Gmelin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [request for testing] isl, cyapa on chromebooks
On 09/10/2016 23:22, Warner Losh wrote:
> There seems to be enough information present in the smbios data to
> know what devices are at what addresses. Perhaps we should use it as
> much as possible in well controlled situations to move this knowledge
> into the OS.
So, I was thinking about maybe doing something like this to preserve the status
quo, to avoid requiring manual hints and to lay a foundation for the proper
Chromebook I2C slave discovery:
static struct {
uint32_tctlrid,
const char *name;
uint_t addr;
} slaves[] = {
{ 0x9c628086, "isl", 0x88 },
{ 0x9c628086, "cyapa",0xce },
}
static void
chromebook_i2c_identify(driver_t *driver, device_t bus)
{
device_t controller;
device_t child;
int i;
/*
* A stop gap approach to preserve the status quo.
* A more intelligent approach is required to correctly
* identify a machine model and hadrdware available on it.
* For instance, DMI could be used.
* See
http://lxr.free-electrons.com/source/drivers/platform/chrome/chromeos_laptop.c
*/
controller = device_get_parent(bus);
if (strcmp(device_get_name(controller), "ig4iic") != 0)
return;
for (i = 0; i < nitems(slaves); i++) {
if (device_find_child(bus, slave->name, -1) != NULL)
continue;
if (slave->ctlrid != pci_get_devid(controller))
continue;
child = BUS_ADD_CHILD(bus, 0, slave->name, -1);
if (child != NULL)
iicbus_set_addr(child, slave->addr);
}
}
static device_method_t chromebook_i2c_methods[] = {
DEVMETHOD(device_identify, chromebook_i2c_identify),
{ 0, 0 }
};
static driver_t chromebook_i2c_driver = {
"chromebook_i2c",
chromebook_i2c_methods,
0 /* no softc */
};
static devclass_t chromebook_i2c_devclass;
DRIVER_MODULE(chromebook_i2c, iicbus, chromebook_i2c_driver,
chromebook_i2c_devclass, 0, 0);
MODULE_DEPEND(chromebook_i2c, iicbus, IICBUS_MINVER, IICBUS_PREFVER,
IICBUS_MAXVER);
MODULE_VERSION(chromebook_i2c, 1);
The idea is that this is a driver that listens for new iicbus-es and adds isl
and cyapa devices to a bus if some criteria are met.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
